Welcome to the homepage of Ardomotic. This is an open-source interactive web interface for arduino.
You can create a custom interface with your own devices and sensors, schedule actions and make the
system respond to events, and even create small programs, all within a fully customizable web UI.
This version is still in beta stage, so it is not yet complete, but it is already close to the final release.
Better than a long explanation, here is a short video showing you the different possibilities. ;)
|Ardomotic 2.0 introduction video (3m27s)|
To try out Ardomotic we don't even need an Arduino. It is possible to test many of the interface features without the need to connect to a server. Of course this means nothing will be saved, and nothing will actually be controlled, the purpose is to test the configuration interface and explore all the possibilities. This demo configuration has several tabs, each one corresponding to possible different utilizations of the system.
Here is a bullet-point list of the main features in the most recent Ardomotic version (2.0b as of now).
These are all features we can configure using the graphical interface, no programming required.
Short features list:
Use the GUI to customize your interface. All the elements can be repositioned, zoomed, rotated and re-ordered. Aditional graphical elements can be added, like text, images, blocks of HTML code, even live video streams.
Always in Sync
All the open windows are always in sync. Any change to the system executed in one window is reflected immediately on all windows. In case of a network failure the system re-connects automatically.
The server can be password protected. Different users can be created with different permissions.
Most elements in the configuration windows have pop-ups describing their functionality and/or possible list of values they accept.
Use custom interactive animations to represent your system. Use the supplied animations or change/create them from scratch using your own images. These animations change in sync with the system state.
Connect your own devices to Ardomotic any way you like (digital/analog pins, serial, radio, ethernet, ir, etc). Scan signals from your own remote controllers and reproduce them when necessary.
Get real-time updates of any sensors connected to the server, and use the values just to display the data or to trigger changes in the system.
Define configurable profiles, allowing you to set the whole system to a specific state with a single click.
Create schedules to perform specific actions based on recurring time intervals or weekdays.
Create triggers to perform specific actions based on sensor values.
Program sequences of actions that can be triggered or scheduled to start, stop, pause or run step-by-step.
Detailed features list:
The GUI (Graphical User Interface) is a big part of Ardomotic. It is possible to customize most of the elements in the page, both user created elements and system elements/menus/windows.
Every graphical element (image, Animation, custom HTML block) can be customized. Using the mouse buttons and scrollweel, it is possible to move/rotate/resize/re-order any element in order to create the desired interface. It is possible to add purely graphical elements to the page, that can be anything from a simple line of text to a block of html containing part of another page or an embedded video stream.
Elements can be separated in different tabs for a better organization. We can also customize the colors and dimensions of most elements in the page (background, text, margins, etc).
Ardomotic uses Websockets to communicate, creating a permanent 2-way connection between the browser and the server. This allows the server to inform all the connected clients whenever something changes in the system, and the changes will be visible instantly in all connected clients. Even if we add/remove components from the system while there are several sessions open in different browsers, as soon as we save the new settings all the changes will be visible in every browser automatically.
There is also a System Monitor, where we can monitor in real time the ping time to the server, the number of active connections, the free ram on the server and the number of loops per second. The system has a limit of 3 connected clients simultaneously (this is a limitation imposed by the chip used on the Arduino Ethernet shield).
The server can be completely open or protected. Different users types can be created with specific user levels, allowing them limited levels of access to the system. Note that the authentication process is NOT encrypted, meaning that someone with access to the network and the proper knowledge can get try to find the credentials. It is not possible to use encryption on the Arduino simply because it does not have enough resources to process it.
There are four different layers of access:
Viewers can only see the current state of the system.
Controllers can view the state of the system and interact with it, enabling or disabling the existing elements.
Editors can not only interact with the system but also add/remove/edit components.
Administrators have full access to the system. They can change the base configurations of the system, such as the network settings, levels of security, and manage the existing users.
The interface has a built-in help option to make it easier to configure. While the Help mode is active, pop-ups appear in most of the elements on the page. These pop-ups contain an explanation of what that element does, and what values we can use (if the element is a textbox or similar element where a value can be inserted).
There is a built-in animation design interface where each user can create custom animations or modify the existing ones. These animations can then be used to represent and control the Devices and Sensors in the system. The animations will respond to the state of the elements they represent, adjusting their position between a minimum and maximum value. If a Device is turned on, off or dimmed or a Sensor value changes, the animation automatically updates accordingly.
There are several animation types:
In fade animations there are two different images, and the animation fades from one to the other as the value of the element changes. Example: with 2 images of a light bulb, one in black and the other in yellow, fading from one to the other will create the illusion of the light turning on and off smoothly.
Slide animations have a static image that never moves, and another image that will slide in a straight line over the static image. All the relative positions/directions are configurable. The sliding image moves as the value of the element changes. Example: using a image of a window view as the static image, and an image of window blinds as the sliding image moving vertically, we can create the effect of a window opening and closing.
Similar to the slide animations, these also have static and movable elements, but in this case the movable elements rotate around a configurable point. All the angles and axis are configurable, and the image rotates as the value of the element changes. Example: using a gauge background as the static image, and any pointer as the movable image, we can create a gauge meter to display the value of a sensor.
Devices are the components of the system that we want to control. There are several device controllers, and also several device types. The device controller specifies how the device is connected to Ardomotic. The device types represent when the device turns on and off. What the device actually is will be represented graphically by the device animation.
Devices can also be configured to be dimmable, meaning that instead of just turning on and off they can also operate within a range of values. This range of values can be specified for every device, and is handled differently depending on the controller being used.
Existing device controllers:
Devices can be connected directly to the Arduino pins. Additionally, if the device is configured as dimmable, use only Arduino PWM pins to create the dimming effect.
When using the serial port as the controller, any interaction with that device will result in a message being sent through the specified serial port. The contents and frequency of these messages will depend on the device type. All the information about the current device state is sent in each message. This options allows the Ardomotic server to send instructions to another Arduino or any other device that can receive orders via serial port.
Similar to Serial, but sends the messages through the internet to a specific IP address by UDP.
With these controllers we can capture the transmission from any Radio or IR remote controller. Just connect the right receiver for whatever transmitter you want to use to any digital pin on the Arduino. Ardomotic is able to capture the transmission, and save it so that it can be reproduced later to control any device we want. Bear in mind that some high-security controllers (like cars and garage doors opener) have more complex protocols and send different codes every time, so in those cases it will not work. Whenever a signal is captured a graphical representation is displayed so we can see if they keep changing or remain the same.
When using custom hardware that cannot be fitted in any of the previous categories, we can also add custom code to the system. Simply add some basic information and functions to the file "Outputs.h" to handle your hardware (the file contains instructions on exactly what you need to add). All the relevant values will be passed to your controller function and you can handle them as you desire.
Existing device types:
Switches are devices that turn on and off when clicked. At any time you can decide to turn them on, off, or toggle their state.
Timers are devices that turn on when clicked, and turn off automatically after a pre-set amount of time. Instead of turning them on and off, when you interact with them the timer resets, making them stay on for longer.
When a blinker is activated, it keeps turning on and off at a configurable frequency. Clicking them starts/ends the loop.
Activators are devices used to send custom messages/commands via different transmission methods. They can be used to send custom text messages to other arduinos using a serial port or Ethernet. They can also be used to take samples of Infrared/Radio signals and reproduce them later on demand. When an activator is clicked, it keeps repeating the same message in configurable intervals until we stop clicking it.
WOL devices are used to turn on computers with the Wake On Lan protocol. We simply supply the MAC address of the computer and we can turn it on from anywhere by clicking on the device.
Sensors are the inputs for external data to enter the system. The data can arrive from different data sources. These sources can supply numerical or string data. The data can be used simply for display purposes, or to perform any action we want by using it to create Triggers. When the source of the data is numerical, we can configure the sensor animation to constantly match the value being read. Additionally, we can also choose to display the exact value.
Existing sensor data sources:
Digital pins can detect if their value is High or Low, and that value is converted to a numerical value (1 or 0 respectively).
Analog pins can read a value between 0 and 1023, that corresponds directly to the voltage connected to that pin. This makes them a very easy way to interact with external hardware that uses analog output.
We can read data from the serial ports 1, 2 and 3 from the Arduino. This data arrives in strings, but can be parsed later by the triggers if it contains any numerical data.
When using custom hardware that cannot be fitted in any of the previous categories, we can also add custom code to the system. Simply add some basic information and functions to the file "Inputs.h" to handle your hardware (the file contains instructions on exactly what you need to add). Your custom function will read the values from the your sensor and the values can be integrated with all the features Ardomotic provides.
Schedules can be configured to perform any Action at specific hours/dates combinations. They can be used simply to turn something On/Off, or as part of more complex behaviours, by combining them with other Schedules, Triggers or Programs. We can easily do something like having a heater turn on when is cold, but only during week days, between 9:00 and 17:00.
The schedules can be configured to occur only once, to repeat a specific number of times, or to repeat forever. In the schedule lists we can see in real time which schedules have already expired, how many repetitions are left in the ones that are still running, and the time for the next occurrence. The repetitions will still count even if the Arduino is turned off. For instance if a schedule is programmed to turn on a light every hour 24 times, even if the power fails for a few hours in the middle of the schedule the last repetition will be 24 hours after the first one. The repetitions that were supposed to happen while the power was off will never happen, but the remaining ones will still be in sync with the desired time.
The schedule executes once at the specific time/date and never repeats again.
The schedule executes at the starting time/date, and then repeats at a fixed interval until it completes the desired number of repetitions. The repetition period can be configured from milliseconds to months.
The schedule executes at the starting time/date, and then repeats at the same hour on the selected days of the week until it completes the desired number of repetitions.
Triggers are used to make the system respond to external data that is read through the Sensors. We can set up each trigger to read data from a specific Sensor, parse the data if necessary, and then test the values to decide if an Action is executed or not. They can be used simply turn something On/Off, or as a part of more complex behaviours, by combining them with other other Schedules, Triggers or Programs. Strings of data can be parsed to extract the right value to use. Consider a sensor that would output a string like "X:134 Y:317". It is possible to create a trigger to extract the value of X or Y and use it to perform the chosen test.
The triggers perform a specific test with the values they get, and they can change the desired target accordingly. We can perform the actions when the test becomes true, false or both. For instance, let's say we have a sequence of lights we want to animate only when it is dark. We can create a Program with the desired animation sequence, and then use the Trigger to make the Program start when it is dark and stop when it is bright.
The trigger activates whenever the Sensor changes the value.
The trigger activates when the Sensor value is equal to the test value.
The trigger activates when the Sensor value is different from the test value.
The trigger activates when the Sensor value is greater than the test value.
The trigger activates when the Sensor value is smaller than the test value.
The trigger activates when the Sensor value is between the two test values.
The trigger activates when the Sensor value is not between the two test values.
True, do nothing when False
The trigger activates and performs the chosen action when the test becomes true.
True and False
The trigger activates and performs the chosen action both when the test becomes true or false.
True, opposite when False
The trigger activates and performs the chosen action when the test becomes true, and performs the opposite action when the test becomes false.
Programs are used to create complex sequences of actions. We can create programs with delays, conditions and loops. Several programs can be running simultaneously. We start and stop running each program any time, pause and resume the execution, or run it step-by-step. It is also possible to group actions together so they are executed in a single step.
The programs are created and edited in the graphical interface. Add lines of code by selecting properties or elements from your system.
When a program runs, there is the option to see what lines the program is executing in real-time. This can be used for debugging or demonstration purposes.
This is an example of a program that simulates a traffic light where the green light is on for 20 seconds, then the yellow light blinks 4 times during 8 seconds, then the red light in on for 12 seconds:
Disable Device: Yellow
Disable Device: Red
Enable Device: Green
WAIT (10) seconds
Disable Device: Green
REPEAT (4) times
Enable Device: Yellow
WAIT (1) second
Disable Device: Yellow
WAIT (1) second
Enable Device: Red
WAIT (12) seconds
Program line types:
A program line can do any Action the system can do, optionally using parameters from other components in the system. For instance, we can set the dim value of a Device to the dim value of a different device, or to the value read from a Sensor.
Creates a delay in the program for a specific amount of time. The duration can be a fixed number, or a value obtained from a variable or another component in the system. For instance, we can set the delay proportional to the dim value of another device, to make a led blink faster or slower depending if another device is dimmed to a high or low value.
We can create IF-THEN or IF-THEN-ELSE blocks using any variable from the system to create more complex programs
Repeats can be used to repeat a block of instructions a fixed amount of times, or while specific conditions are met. These can be used as one would use a FOR or a WHILE cycle in any other language.
It is possible to store values in variables, that can later be used to decide the flow of the program using the conditions or the repeat instructions.
This is a less standard programming feature. You can create blocks of instructions, and these instructions will all be executed in a single step of the program. They have no influence on the program when it is running normally, only in step-by-step mode.
An action is any kind of modification to the state of the system (enabling a sensor, toggling a device, running a program, etc). Actions can be executed in response to different events:
Clicking an element in the UI.
Executing a Trigger.
Executing a Schedule.
Running a line in a Program.