Search by Support Category: Miscellaneous
This guide explains how to pull data from the SilentGliss API so you can control it directly from uOS.
What this guide will cover:
- How to control SilentGliss window coverings in your home.
- How to add that API into uOS.
Important: you must have the IP addresses first
You can get the IP address of your SilentGliss gateway device:
- Use a network discovery app like Fing to find the SilentGliss gateway on your network.
What a typical SilentGliss API command looks like
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.
Testing your APIs
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:
- Make sure the IP address is correct.
- Make sure that you do not have any typos.
- Ensure that your IDs are correct and that you’re observing a light in the correct room and location.
- Make sure that the structure of the API matches our example no spaces, no special characters, data is in the correct case (often lowercase).
How to add your APIs into uControl
Need more help with the API? Get in touch.
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.
What this guide will cover:
- How to control KNX devices in your home.
- How to add that API into uOS.
Important: you must have the gateway IP address first
You can get the IP address of your gateway by:
- Use a network scanner application like Fing on your mobile phone to scan your network.
- You can also get the IP address from the properties tab of the device in KNX’s ETS.
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.
What a typical BAOS API command looks like
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.
Understanding what the variables in the API above mean:
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.
Testing your APIs
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:
- Make sure the IP address is correct.
- Make sure that you do not have any typos.
- Ensure that your IDs are correct and that you’re observing the correct device.
- Make sure that the structure of the API matches our example no spaces, no special characters, data is in the correct case (often lowercase).
How to add your APIs into uControl
Need more help with the API? Get in touch.
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.
Before you begin, you will need:
Important: You must have the IP address for AudioFlow first
You can get the IP address of your AudioFlow switch by:
- Using a network scanner application like Fing on your mobile phone to scan your network.
- Download the AudioFlow app and connect it to your network. From here go to settings, and you will see its IP address.
Step 1 – Getting Data
Step 2 – Build Function
Need more help with the API? Get in touch.
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.
What this guide will cover:
- How to control Shelly lighting in your home.
- How to add that API into uOS.
Important: you must have the IP addresses first
There are a few ways you can get the IP address if your Shelly device:
- Use a network scanner app like Fing to find Shelly on your network.
- Log into your wireless router and look for Shelly in the DHCP table.
What a typical Shelly command looks like
/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
Testing your APIs
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:
- Make sure the IP address is correct.
- Make sure that you do not have any typos.
- Ensure that your IDs are correct and that you’re observing a light in the correct room and location.
- Make sure that the structure of the API matches our example no spaces, no special characters, data is in the correct case (often lowercase).
How to add your APIs into uControl
Need more help with the API? Get in touch.
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.
What this guide will cover:
- Understanding switching outputs, batches, ports and their status.
- How to create a NETIO API so that you can control power in the property.
- How to add that API into uOS.
Important: you must have the IP for NETIO first
You can get the IP address of your NETIO by:
- Using a network scanner application like Fing on your mobile phone to scan your network.
- Log into your wireless router and look up NETIO in the DHCP table.
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.
What a typical NETIO API looks like
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.
Understanding what those variables in the API above mean:
This is the authentication and is user definable and can be changed to the name of the device owner on the NETIO web UI.
output=
This is the command variable(s):
- 0 – Turn OFF
- 1 – Turn ON
- 2 – Short OFF delay (restart)
- 3 – Short ON delay
- 4 – Toggle (invert the state)
- 5 – No change
- 6 – Ignored
“&”
This sign allows you to add parameters to your command, every command must be linked by it.
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 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:
- Make sure the IP address is correct.
- Make sure that you do not have any typos.
- Ensure that your IDs are correct and that you’re observing the correct PDU switch.
- Make sure that the structure of the API matches our example no spaces, no special characters, data is in the correct case (often lowercase).
How to add your APIs into uControl
Need more help with the API? Get in touch.
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.
What this guide will cover:
- How to gather information about your lights and use this to set their states.
- How to create a Philips Hue API so that you can control any light in the property.
- How to add that API into uOS
Important: you must have a developers account first
Before you can access the full Philips Hue API you must have made a Philips Hue Developer account.
Retrieving the IP address
There are a few ways you can get the IP address of your Philips Hue device:
- Use a network scanner app like Fing to find Philips Hue on your network.
- Use Philips Hue broker server discovery process.
- Log into your wireless router and look for Philips Hue in the DHCP table.
- The Philips Hue app – Start the Hue app and push link to connect to the bridge. Use the app to find the bridge and try controlling lights to ensure that everything is working. Then, go to the settings menu in the app, go to Hue Bridges, select your bridge and then the IP address of the bridge will be revealed.
Generating an access token
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:
- Start off by typing /api into the URL.
- Then go ahead and type
{"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. - Lastly, select your method as POST.
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.
Testing your APIs
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:
- Make sure the IP address is correct.
- Make sure that you do not have any typos.
- Ensure that your IDs are correct and that you’re observing a light in the correct room and location.
- Make sure that the structure of the API matches our example no spaces, no special characters, data is in the correct case (often lowercase).
How to add your APIs into uControl
Need more help with the API? Get in touch.
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.
Please read the instructions (included in the .zip file) carefully before using this software.
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.
WiFi on Zone Processor Setup Guide
This guide will walk you through the process of changing your Zone Processor (ZP) device’s network connection from a wired Ethernet setup to a wireless (WiFi) setup.
This process involves three main phases:
- Initial Setup: Configuring the device while it’s connected via Ethernet.
- Temporary AP Mode: Using the device’s own Access Point to connect to it directly.
- Final WiFi Mode: Connecting the device to your building’s main WiFi network.
Part 1: Initial Wired Setup
Before you can configure the WiFi, the ZP device must first be set up on your network using an Ethernet cable.
- Connect the ZP device directly to your router or network switch using an Ethernet cable.
- Power on the device.
- On a computer connected to the same network, you will need to find the ZP’s current IP address.
Note: You can typically find this by using the uControl app or a network scanner.
- Open a web browser and type that IP address into the address bar to access the device’s web interface (GUI).
Part 2: Switch to Access Point (AP) Mode
Next, you will temporarily turn the ZP device into its own wireless hotspot.
- In the ZP’s web interface, navigate to the “Network” section.
- Find the “Device Mode” setting.
- Change the mode from Ethernet to Access Point.
- Save the settings.
Part 3: Connect to the ZP’s Temporary Network
Your computer will lose connection to the device when it restarts. You must now connect to the new temporary network it is broadcasting.
- On your computer or mobile device, open your WiFi settings.
- Look for a new network name (SSID) broadcast by the ZP device. It starts with
HDA-ZP(Example:HDA-ZP5-146D).

- Connect to this network. You will be prompted for a password.
Password:hdanywhere - Your device is now connected directly to the ZP, not to your main network.
Part 4: Switch to WiFi
Now that you are connected to the ZP’s temporary network, you will give it your main WiFi network’s details.
- Open a web browser.
- In the address bar, type:
192.168.100.1
This is the ZP’s default IP address when it is in Access Point mode. - Once the web interface loads, navigate to the “Network” section again.
- Change the “Device Mode” from Access Point to WiFi.
- Save the settings.
- Enter your WiFi Network and password then Save the settings again. The device will disconnect you from its temporary network.
Part 5: Locate Your Device on WiFi
Once the ZP device reboots, it will be connected to your network via WiFi. It will have a new IP address assigned by your main router.
You must now find this new IP address to access the device:
- Using the App: The simplest method is to use the uControl app, which has a built-in network scanner to find the device.
- Using Your Router: You can log back into your router’s administration page and check the “DHCP Client List” for the ZP device to see its new IP.
- Using a Network Scanner: You can use a third-party application (like Fing on mobile or Angry IP Scanner on a desktop) to scan your network and locate the ZP’s new IP address.
Once you have the new IP address, you can use it to access the ZP’s web interface as normal. Your device is now successfully connected via WiFi.
Important: The tail end connects into your MHUB system
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.
If you have a Sky Q 4K capable box and 4k capable displays this support post will guide you through getting the most out of your setup when using HDA systems.
Does my HDA system support Sky Q maximum output
You will need to confirm if your system is capable of passing the signal from your Sky box. Only the following systems are supported -
- MHUB PRO 2.0
- MHUB S
- MHUB U systems running MHUB-OS version 8.26 or greater
If your system isn’t listed above it may still support Sky Q at 4K, however, HDR will not be supported.
Configuring the MHUB System
You may need to do some minor configuration on the MHUB to get the most out of the Sky Q. To do this you will need to adjust the MHUB’s EDID settings for the input where the Sky is connected. Where possible we would recommend copying the EDID from your display. To configure EDID settings follow this guide – EDID Settings
Setting Sky Q to output 4K 10 bit
After setting the EDID on your MHUB you will then need to set the output of the Sky Q system. To do this Press the HOME button and scroll down to settings. Then in the settings menu scroll down to SETUP, then AUDIO VISUAL.
The first option will be Picture resolution, use the D-Pad and select 2160 [UHD]. You will then get onscreen instructions to select either 10-bit or 8-bit colour. Select 10-bit colour, then confirm everything is fine by following the onscreen instructions. You can also check out Sky’s guide here – Changing Resolution
There is a timer to confirm the picture is fine, if it expires before you can confirm simply press LEFT and ENTER after selecting 10-bit colour whilst the screen is still black.
Setting Sky Q to output Dolby Atmos Audio
to get Dolby Atmos from your sky box you need to change the Audio settings. These are located in the same menu as the video settings above. Scroll down to DIGITAL AUDIO OUTPUT HDMI. The setting required is ‘Dolby Digital Plus’.
Please be aware if any display cannot handle a 4K output and decode Dolby Digital Plus you may get no video and audio. If this happens you may have to adjust these settings.
MHUB and XTND systems use IR passback to pass signals from your Sky remote back to the Sky Q box. By default, these remotes ship to customers with IR disabled. In order for your remote to work with your HDANYWHERE system you will need to change the mode of operation from Bluetooth to IR.
If you would like to change your Sky Q remote from Bluetooth to IR and vice versa just press 4 & 6 together AFTER you have paired the remote.
Siri Shortcuts & HDANYWHERE.
With any Apple device along with an MHUB or Zone Prossesor you can use Apple “Hey Siri” and our API to send commands to uControl/uOS to control virtually any display, source inputs plus lighting control.
Below you will find a step by step how-to guide.
If your MHUB is marked with “TPC” then it is capable of passing a HDR picture to your display. There are a number of reasons why HDR may not be fed through your HDA device. This support post aims to troubleshoot the most common reasons and how to resolve them.
Important: there are different versions of HDR, make sure your display supports the format your source is outputting!
There are multiple variants of HDR such as HLG, HDR10+ and Dolby Vision, please ensure your display supports the relevant HDR technology.
When connecting your HDR enabled source and display to a HDA system you may need to adjust some settings to get it to work.
- First, disconnect the source and connect it directly to your display. Do you get HDR?
- Ensure you are using High Speed HDMI Cables, this is important as long HDMI cables (over 5m) unless Active or Fibre will not work.
- Was you HDA device manufactured before 2019? Does it have TPC markings or 18G/18Gbps on it anywhere? If it doesn’t then there is a good chance that your HDA device does not support HDR as it was made before the specification was finalised.
- Does your HDA device support scaling? If so please ensure it is set to bypass.
- Copy or set a custom EDID directly from your display. This post explains how to copy EDID directly from your display.








