Choosing a z-wave controller

In the last post, I looked at solutions for starting out my automated home and decided to go with z-wave as the primary protocol to start investing in. Now, we need to start with the central point, the primary controller which is going to act as the central hub for the network.

The first thing that I needed was a controller. There are quite a few options for this, including off-the-shelf options from companies like Fibaro and SmartThings as well as applications which can be installed on a home server. My initial concern was this is a fairly new market that isn’t very big yet and I didn’t know which of the companies were going to last and keep supporting the hardware that they had made. There was of course the cost aspect with the majority of off-the-shelf solutions costing over £100.

Like the SmartThings hub, both OpenHAB and Domoticz offer support for protocols other than zwave, including Phillips Hue, Nest, MQTT, IFTTT and Twitter. So they can integrate with other solutions that might be useful.

Being happy to manage a small Linux server, I decided that I wanted to run a software based controller rather than an off-the-shelf box as it could then be customised to do more if I want it to in the future. It also makes it potentially easier to switch software at a later date too. The key players in the home automation software space seem to be Domoticz and OpenHab. They both look decent and seem to have good support, though OpenHab offers an official iOS app while Domoticz seems to leave this to third parties. OpenHab also seems to have a very responsive forum with the developers quickly responding to people’s issues which settled it as the winner.

With the application chosen, I needed somewhere to run it. Although the household computer is usually running, “usually” isn’t going to cut it if it’s a critical part of the house’s lights and heating. The Raspberry Pi is cheap enough and has a desirably low energy footprint to be running constantly so it seemed the perfect choice. Out of the box though, the Raspberry Pi can’t control zwave devices as it lacks the necessary hardware. This is easy enough to solve, with several manufacturers making USB radios (that would also be compatible with any other machine with a USB port) and the Razberry daughterboard which is dedicated to the Pi. In choosing a hardware radio, definitely consult the documentation of the application chosen to make sure there are no compatibility issues though.

Together, the Pi and the Razberry came to nearly £100 – not much cheaper than the dedicated boxes – but the Pi can at least be re-purposed if it turns out not to be the best solution, and is flexible in that it can run other things too.

Getting started with Home Automation

In the home automation space, I first started looking at the central heating controls as that seems the place with the most to gain. Too often our heating is on when we’ve gone out—or off because we would ordinarily be out at that time—what if the heating knew when we were home and I didn’t have to worry about fiddling with the heating schedules?

After getting lost in the various central heating and hot water control products though, I realised that it would inevitably go further than that – it would be great to control lights, alarms and just about everything else. So, I started looking for something (or a suite of things) that would integrate and talk to each other.


LightWave RF

This is the stuff you might find on display in your local B&Q. I originally started looking into LightWave as James has some experience with it, and on the whole it sounds like an almost perfect solution for controlling lights–

  • their hardware is really good looking and fairly inexpensive
  • the switches just replace a standard UK switch plate
  • there are things like the additional stick-on battery switches so that switches can be added without drilling, cutting or wiring
  • there are lots of add-ons available such as ambient light sensors and motion sensors.


  • LightWave just doesn’t play all that well with other technologies. There is software available that can talk to LightWave but James had some major issues with latency that are a bit of a deal breaker.
  • The motion and contact sensors seemingly can only be used to turn on lights, so can’t be used as an alarm system by sending a notification to my phone.
  • The switches don’t have the concept of a “state”. So they can be switched remotely, but you are blind as to their current status unless you can see the actual light. That’s no good then for checking that lights haven’t been left on while I’m at work.

On the whole, the concept is ideal. The idea of replacing just a small number of switches is far more appealing than a concept like Hue which involves replacing every light bulb at something like £40 each. I counted, and with various lamps our living room has 9 light bulbs alone. More importantly all of the technologies have to be transparent to those who don’t know about them. For example, our parents are often over to help out with child care, and they wouldn’t be too impressed if they needed an app to switch on the light.


Zigbee is one of the IoT protocols, and is used in products like the Phillips Hue. When researching though, there doesn’t seem to be a market of products that can interact. Rather, it seems like companies like Phillips are using it in a proprietary fashion.


One of the emerging standard seems to be z-wave. Z-wave is a protocol that supports most uses – including lights, sensors, alarms and just about anything else. The light switches don’t seem to be there yet, as most of them are awful looking white plastic things unless money isn’t an option. There aren’t any power socket faceplates, just the plug-ins that are roughly analogous to the timer switches we’re all used to. But it does everything else, and surely the market will catch up and make these missing products (or start to compete on price!).


So, after some deliberation I’m going to start out slow and try out z-wave as the backbone of my automated home. It seems that there are some good, affordable products out there using z-wave and conceptually they work as I want them to.

Debugging Oracle SmartView

Smartview can be a bit of a pain when it doesn’t work. The error messages tend to be both very vague and user-hostile with phrases like “Logon Error!” and “jbips.common.jbipsexception”.

My first port of call is usually to check the server side log, located at <>/servers/bi_serverN/logs/jbips.log. Often this will contain some further information for example if the user has provided an invalid username/password or is using an incompatible version of SmartView.

This doesn’t always help though, as the error might not get as far as the server. In that case the client log is useful, though when I just looked for mine and couldn’t find it, until I realised that logging was disabled on my client (therefore that’s likely the default).

To find the SmartView client logging settings, look under the Smart View pane in the Office ribon, and select Options. Then the logging settings are under Advanced. Check the box to route messages to file, and set the log level to something appropriate (Errors or Warnings sound like a good place to start, increasing from there if necessary).

Error: biserverxmlcli COLOCK_ISSET

When trying to apply an XML patch to our repository using the biserverxmlcli command (as per section 6.3.3 of the Oracle® Fusion Middleware XML Schema Reference for Oracle Business Intelligence Enterprise Edition) we started getting the nQSError codes 46036 & 43113 with the specific message:

Internal Assertion: Condition COLOCK_ISSET(value), file server\objectmodel\Src\SORpObject.cpp

Well, that wasn’t too specific so we spent a while searching around for what was causing it. We checked the patch file, and the repository file we were trying to apply the patch to and both were fine. Searching the internet and MOS returned details of an old issue that we already had the patch applied for, and it was working the day before, so it was unlikely to be a specific bug.

It turned out that the admin account we were using to apply the patch had insufficient privileges to apply the patch to a running repository. When running the command as another administrator everything worked fine, as did the original account when we had corrected the permissions!

Node Manager Unreachable

Today I hit a problem were Enterprise Manager was reporting managed server BI_server1 was down. That was a surprise as I was pretty sure it had just started with no problems!

Refresh EM. Still reported as down.

Restart everything. Still “down”.

Okay, back to the WLS Console. Nope, BI_server1 is definitely running. So why doesn’t EM agree?

After a bit of digging, it turned out that the Node Manager was unreachable, according to WLS Console. And the node manager was logging:

<WARNING> <There was a problem initializing the domain <domain> at 'D:\OBI\user_projects\domains\domainName'. Please make sure that this domainName: <domain> is registered and is fully enrolled for this nodemanager at: 'D:\OBI\user_projects\domains\domainName'.>
<WARNING> <I/O error while reading domain directory> Invalid state file format.

I followed a few guides to re-register the domain with Node Manager, and each time I tried it reported back a successful registration but the issue remained unresolved.

For server bi_server1, the Node Manager associated with machine MyServer is not reachable.

A search on Oracle support for the above turned up Doc ID 1293552.1, NodeManager not Reachable: Invalid State File Format.

I opted for option 2, stopping the node manager and admin server then deleting the following files:

…user_projects\domains\\servers\bi_server1\data\nodemanager\bi_server1.state …user_projects\domains\\servers\bi_server1\data\nodemanager\bi_server1.lck …user_projects\domains\\servers\bi_server1\data\nodemanager\

After starting up Node Manager, Admin Server, and BI_Server1, then restarting all the managed services in EM, the environment was back up.

Customising OBIEE’s colour palette

OBIEE 11g Default Colour SelectorBy default the OBI colour palette may not be to everyone’s taste or corporate branding. Using the custom messages functionality of OBI to customise it we can change the colours in this palette!

The custom message that we need to customise is {Oracle_Home}/bifoundation/web/msgdb/messages/commonuitemplates.xml so we’ll copy that to our custom messages directory for editing.

The message we’re interested in is named “kuiColorSelectorColors” <WebMessage name="kuiColorSelectorColors" translate="false"> so the easiest way is to search the file for that and delete out the other messages.

Within the kuiColorSelectorColors message we see three parameters, two for the dimensions of the palette: knFormatColorsRows = 6; knFormatColorsCols = 8;

11g custom color selectorSo by default the palette is 6 rows by 8 columns for a total of 48 colours. We can change this to increase or reduce the number of colours the palette will hold.

The third parameter is an array definition of the colour values in their hexadecimal format: kaFormatColors = new Array(“#CC99CC”,…);

Obviously we need to define the right number of colours for the volume of our palette (I’ve not tested what happens if we define too many or too few colours here). Interestingly the palette will fill from this array starting with the bottom left corner, filling to the right and upwards one row at a time – not from the top as you may expect.

Customising the OBIEE login page

In the last post we showed how to get OBIEE set up for customisation. Now lets look at using that to start making OBIEE look like it belongs a bit more in our company.

Just about all of the text on the OBIEE pages is customisable, as all of that text is defined in XML files that are loaded when the Presentation Server is started. Previously we set up a CustomMessages directory that was made available to OBI through weblogic. This directory is the one that PS now checks first when starting up, for the XML messages files and takes any that it finds there in preference to the default messages that were installed with OBI.

Creating a Custom Message

The easiest way to create the first custom message is to copy one of the defaults. So, for the login page lets take

  • {Oracle_Home}/bifoundation/web/msgdb/l_en/messages/logonmessages.xml

and copy it to

  • …CustomMessages/l_en/logonmessages.xml

When we look at the file through a text editor, we see that each piece of text on the logon screen is contained within a WebMessage XML tag. We only need to keep the ones that we are editing, if we want the defaults then we can delete them from our custom file.

So, for example, we use an LDAP source for authentication. As such people use their network password to log on to OBI. To stop any confusion, we can change the “Password” field to hold the label “Network Password”. After that our custom XML file will read as:

<?xml version="1.0" encoding="utf-8"?>

<WebMessageTables xmlns:sawm="">
<WebMessageTable lang="en-us" system="Logon" table="Messages">

<WebMessage name="kmsgAuthenticatePassword"><TEXT>Password</TEXT></WebMessage>


Setting up OBIEE for customisation

RittmanMead already have a good and detailed post on this, but basically:

Configuring the Directory

First, we need a directory to use. Either on the server or at least somewhere it can access.

To get this directory ready we first copy in the WEB-INF directory from {MIDDLEWARE_HOME}\instances\instance1\bifoundation\OracleBIPresentationServer\coreapplication_obips1\analyticsRes

We also have to copy the skin (sk_blafp) and style (s_blafp) directories from {Oracle_Home}\bifoundation\web\app\res and rename them to sk_custom and s_custom respectively. While we’re there we’ll make a CustomMessages directory too

The UI directory now has three subdirectories:

  • sk_custom
  • s_custom
  • CustomMessages

Next this directory has to be made available through a web server. For simplicity we will use Weblogic as we have that handy. To expose the directory using Weblogic, it is deployed as a J2EE application using the WLS Console.

  1. Log into the WLS Console, navigate to Deployments then click the Lock & Edit.
  2. Click the install button which has now become available.
  3. Enter the path of the UI directory previously set up and select Next.
  4. Opt to “Install this deployment as an application”.
  5. Select to deploy the application to a cluster, and the bi_server# component part of the cluster.
  6. Customise the name, if you like, and select the option “I will make the deployment accessible from the following location”, the path to the UI directory should be populated below.
  7. Click Finish

There should now be a new application called UI (or whatever you customised the name to) in WLS. Apply the changes and then check the state of the deployment to make sure it is active.

Configuring OBI

Next we need to configure OBI to use the styles and skins from the new location.

Into the InstanceConfig.xml ({MIDDLEWARE_HOME}\instances\instance1\config\OracleBIPresentationServicesComponent\coreapplication_obips1) file we add:


To enable this change, the presentation server component will need to be restarted.