This guide will show you how to update you device in uControl.
From slide 2 if your system is already connected in uControl.
From slide 9 if you have just installed uControl and are not connected to a device.
This guide will show you how to update you device in uControl.
From slide 2 if your system is already connected in uControl.
From slide 9 if you have just installed uControl and are not connected to a device.
If you see a HDANYWHERE or third party device marked with “uControl inside” then it contains our control system inside it. You can find out what it can do by visiting uControl’s website here.
Some devices are marked “AV” where others are “Full”. This is determined by the operating system found on the device. The “full” implementation of uControl can be found in devices which have uControl OS (uOS) inside. “AV” means that the system is running MHUB-OS (MOS) and control capability is restricted to AV only or the devices that are directly connected to the MHUB system.
Full
AV
It may be possible to update your MHUB’s control capabilities by adding a uControl Zone Processor to manage your system instead. Not all models are supported so we recommend contacting us to confirm the level of support first.
*Requires a Zone Processor to be added to the system to upgrade to Full uControl capabilities.
This guide explains how to use Lutrons API protocol to control QS Standalone, RadioRA2, Quantum, Athena, HomeWorks QS, myRoom plus from Lutrons devices.
For the purposes of this guide we are going to assume that your Lutron gateway is on IP address 192.168.1.15 and your uOS device (MHUB, MZMA or Zone Processor) is on 192.168.1.196. We will use this to illustrate all examples moving forward.
Important: This guide assumes that you are familiar with Lutron and know how to use their lighting infrastructure and that your Lutron system is operational before integrating into uOS.
See “Testing your API’s” for more information on Telnet.
#OUTPUT,2,1,75,00:30
#OUTPUT
This is the operation character for executing an action. For more information on these see the slideshow below.
,2
The first number in the string is the ID for the device.
,1
The second number in the string is the action number, which in this instance is enable.
,75
This number sets the level of the dimmer, so in this case 75%.
,00:30
This is the fade time of the dimmer.
Testing your APIs
We recommend that you test every API before you enter them into uOS. All IP based APIs have different requirements when it comes to testing, Lutron’s method is a little different as it needs to be done over Telnet in command prompt.
To test your commands, open up command prompt on your laptop or PC and enter telnet 192.168.1.15 23
Remember, your IP address will be different, you must use the Lutron gateway IP address for this, the port is 23.
You now need to wait for it to connect which may take a few minutes, then you will be asked to login. The username is lutron, and the password is integration. You will now be able to test your commands in the terminal. Observe the device you are trying to control, and see if your commands changes the outcome.
Using a MAC?
If you are using a MAC you can use Netcat to test your API command. To do so open your terminal and enter nc 192.168.1.15 23
Wait for it to connect and then you will be prompted to login. The username is lutron and the password is integration.
If it doesn’t work then try the following:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
This guide explains how to pull data from the SilentGliss API so you can control it directly from uOS.
You can get the IP address of your SilentGliss gateway device:
192.168.1.15/sgbms/v1/device/7/command
This command only shows the structure and does not include the actual action of the command which needs to be included in the body. This will be explained further through the guide.
192.168.1.15/
This is the IP addresss of the gateway, a forward slash (/) needs to be added between each unique variable.
sgbms/v1
This is the URL version of the gateway.
device/7
This specifies we are affecting a device and what its ID is.
command
Command must go at the end as we are performing a POST execution method which is atempting to perform an action.
We recommend testing your API command before entering it into uOS to ensure it works. To do this we recommend installing an application called Postman.
If it doesn’t work then try the following:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
This guide explains how to pull data from KNX’s protocol so you can control it directly from uOS.
Please note: this guide assumes you have access and knowledge of ETS6, and your own KNX/Weinzierl gateway. In this guide we are using a BAOS 774 gateway, but you may have a different one, so refer to this site for more Weinzierl product knowledge.
You can get the IP address of your gateway by:
For the purposes of this guide we are going to pretend that your Weinzierl gateway is on IP address 192.168.1.15 and your uOS device (MHUB, MZMA or Zone Processor) is on 192.168.1.196. We will use this to illustrate all examples moving forward.
http://192.168.1.15/baos/SetDatapointValue?Datapoint=2&Format=DPT1&Length=1&Value=false
The above command will trigger our BAOS gateway to send a telegram to datapoint 2, which will switch off our light.
http://192.168.1.15
The command starts with http:// as it can be sent over a URL, followed by the IP address of your KNX/Weinzierl gateway.
/baos/
This is the device type of a Weinzierl device.
SetDatapointValue?Datapoint=2
Here we are setting this command to send to our KNX data point to two.
&Format=DPT1
This is the sub data point, and sets the rules of which values are allowed.
&Length=1&Value=false
This is the length of the data point type, and the value is boolean therefore setting it on or off.
We recommend that you test every API before you enter them into uOS. All IP based APIs all have different requirements when it comes to testing but the KNX API is great because it can be tested on your browser.
To test your API, open a web browser and enter the full API (including http://192.168.1.15) in the URL window and hit enter.
If the KNX device responds as you expected then your API is working and you can proceed adding it into uOS.
If it doesn’t work then try the following:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
This guide explains how to pull data from the Audioflow API so you can control it directly from uOS, uControl App and uControl Remote.
Important: You must have the IP address for AudioFlow first
You can get the IP address of your AudioFlow switch by:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
This guide explains how to pull data from Shelly’s API so you can control it directly from uOS.
Please note: this guide covers how to execute a command for a Shelly light, if you are using a different device the same logic applies, you only need to change the parameters. Please find the link to Shelly’s API document below for commands relating to different devices.
There are a few ways you can get the IP address if your Shelly device:
/color/0?turn=on&red=0&blue=0&green=255
This only shows the logic of a Shelly command, you may be controlling a relay and therefore need to use different parameters. There will be a link at the bottom which will take you to Shelly’s API documentation where you can find all their codes.
/color/0?
This is the mode of the device and declares it is an RGBW2 controller. If you were writing a command for an automated blind it would be /relay/0?.
turn=on
This affects the state of the device.
red=0&blue=0&green=255
You can test your Shelly command in the URL to see if it works. Make sure to include http:// for it to work properly.
If it doesn’t work then try the following:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
This guide explains how to control your NETIO PDU from uOS, uControl App and uControl Remote.
You can get the IP address of your NETIO by:
For the purposes of this guide we are going to pretend that your NETIO PDU is on IP address 192.168.1.15 and your uOS device (MHUB, MZMA or Zone Processor) is on 192.168.1.196. We will use this to illustrate all examples moving forward.
NETIO ports are simple, port 1 is equal to 1 (p=1) and port 2 is equal to 2 (p=2) and so on. When typing your commands, make sure to follow this logic.
http://192.168.1.15/netio.cgi?pass=1234abcd&output1=1
In the example above we are going to send a command to the Netio PDU (at 192.168.1.15) to execute a power switch turning output 1 to ON.
output=
This is the command variable(s):
“&”
This sign allows you to add parameters to your command, every command must be linked by it.
We recommend that you test every API before you enter them into uOS. All IP based APIs have different requirements when it comes to testing but the NETIO API is great because it is super simple.
To test your API, open a web browser and enter the full API in the URL window and hit enter.
If you get a response in the web browser similar to the one below, and you heard the NETIO PDU tick to signify a switch, then you’re good to take this command and put it into uOS:
If it doesn’t work then try the following:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
This guide explains how to pull data from the Philips API so you can control it directly from uOS, uControl App and uControl Remote.
Before you can access the full Philips Hue API you must have made a Philips Hue Developer account.
There are a few ways you can get the IP address of your Philips Hue device:
For the purposes of this guide we are going to pretend that your Philips Hue bridge is on IP address 192.168.1.15 and your uOS device (MHUB, MZMA or Zone Processor) is on 192.168.1.196. We will use this to illustrate all examples moving forward.
Firstly, we need to make an access token so you can make changes to the lighting.
To start this process, head over to the web browser API by typing in the command below with the IP address specific to your Philips Hue bridge.
http://192.168.1.15/debug/clip.html
Once loaded, you should see a grey “CLIP API Debugger” extension pop up, you then need to type /api/newdeveloper and click GET. You will get a reply in the command response which will state you’re an unauthorised user.
We now need to use the randomly generated username that the bridge creates for you. To incorporate this, do the following:
{"devicetype":"my_hue_app#iphone peter"}
into the message body, we have used Peter as our example but your username will most likely be different so change it accordingly.After clicking POST you should get an error response telling you to press the link button, make sure to go press it on the bridge and then click POST again on the API. This is a security step which stops other people from accessing your lights.
You should then be given your access code which will look similar to the one below, make sure you hold onto this as it will be needed for all commands moving forward.
Now we have our acces token and you’re familiar with using the API, we can start controlling our lights. Watch the slideshow to see how to do execute different commands and what they do.
As Philips API commands require a command for the URL and also the message body, you will have to test if they’re working on the Clip API Debugger program. If they work, they are ready to be added into uOS!
If it doesn’t work then try the following:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
This guide explains how to pull data from the Gude API so you can control it directly from uOS, uControl App and uControl Remote.
There are a few ways you can get the IP address of your Gude device:
This guide explains how to pull data from Rako’s API so you can control it directly from uOS, uControl App and uControl Remote.
For the purposes of this guide we are going to assume that your Rako controller is on IP address 192.168.1.15 and your uOS device (MHUB, MZMA or Zone Processor) is on 192.168.1.196. We will use this to illustrate all examples moving forward.
Important: To get an overview of your project, which for this example is on IP address 192.168.1.15, type 192.168.1.15/rako.xml into a web browsers search engine and enter.
192.168.1.15/rako.cgi?room=5&ch=4&sc=0
In most cases you will either want to turn a light on/off or change the scene in any particular room. To do this you will need to send an API which looks like the example above.
In the example above we are going to send a command to the Rako controller (at 192.168.1.15) to execute a Scene 0 in Room 5 on Light 4.
room=5
This is the ID of the room which your Rako devices are installed in.
ch=4
This is the channel which is how Rako refers to individual lights or RGB values.
sc=3
This is the scene ID.
“&”
This is a separator which is used to separate room, channel and scene values or IDs.
We recommend that you test every API before you enter them into uOS. All IP based APIs all have different requirements when it comes to testing but the Rako API is great because it is super simple.
To test your API, open a web browser and enter the full API in the URL window and hit enter.
Testing your Rako API is as easy as entering it into your favourite browser and hitting enter. If the Rako device does what you expected it to then you’re good to enter it into uOS.
If the Rako device responds as you expected then your API is working and you can proceed adding it into uOS.
If it doesn’t work then try the following:
All HDA staff are able to help with any API questions you might have including any advanced features. Get in touch for help or assistance.
In most cases the core system firmware for your device will not require updating. Most updates for uOS or MHUB-OS can be downloaded from our cloud via the uControl app. This update utility is designed to update low-level firmware and should be carried out carefully.
Please contact us to confirm if your system requires an update and to request your update file.
These can be purchased here: https://hdanywhere.com/products/accessories
If you notice that uControl has stopped responding or your control system is no longer controlling your MHUB or HDA device and you see a screen similar to the one above when you visit MHUB-OS’ IP address then it is likely that a core file within MHUB has become corrupted or is missing.
Generally, this error affects systems that are on very early versions of MHUB-OS, usually versions 7 or lower (at the time of writing 8.15+ is considered stable). On systems that are already on 8+ it is possible to restore the system sucessfully from a backup but earlier ones will need a HDA technician to check your system to identify the damaged system file and repair it.
If your system is out of warranty then there is a charge of 1 unit for this repair. Please contact HDANYWHERE first to arrange a technician slot.