This page last changed on May 24, 2013 by juha.

Lawrie writes:

Currently it is my TCP/IP socket server that integrates with FreeTTS.

One advantage of the TCP/IP server is that it allows me to run the text to speech either on the local machine running OpenRemote, or on any other computer in the house. I mainly run it on a separate music server.

I also have the capability to pause any music playing before saying the text, and to restart it afterwards.


That's true. It is a deployment and topology choice really. I dont think either model is necessarily the only option. If it makes sense to do both, I'm fine with it. If it is external TCP server then it can be either a) just a wiki documentation that explains what values to enter in the current TCP command integration or b) a dedicated TCP protocol to talk to your FreeTTS TCP server.

The advantage of the option (b) above is that it is slightly easier for the end-user if you can present them with options for commands such as 'say' rather than explaining the payload they need to enter into a TCP command. It is mainly perception towards the user. Dedicated feels 'easier' if you're not overloaded with having to understand what TCP means for example

On the other hand, the separate TCP server is an extra installation step that needs to be explained to users as well. Those who are really motivated to get TTS working because they feel they really need it, will go through the extra steps to install it separately if we document those well in the wiki.

Those who are just curious about TTS and want to try it, might give it a skip if they need to do extra installation instead of having things work 'out-of-the-box'. Out-of-the-box also reduces the number of ways users can mess when separate installation is not involved

So I think it is mainly two things – perception on ease-of-use towards the end-user and to some extent technical advantages and disadvantages of different deployment topologies.

Therefore I wouldn't count out either necessarily, and perhaps even giving both deployment options would be feasible?

Best regards,

– Juha

Lawrie writes:

I don't mind doing FreeTTS several different ways. It could be a rules facade, a protocol for local speech synthesis, and another for running it on a remote server.

If it is done as one or more protocols, it needs to be in the designer. How is that done?

It is an XML configuration file that is deployed on the server. Here's an example for generic HTTP: http.xml or dedicated Lutron: lutron.xml

If there's both a facade and protocol, then it makes sense to share the implementation code between the two most likely.

Lawrie writes:

If there is a separately installed server, how would it be issued? Coould it still be part of OpenRemote or would I need to host it as a separate project. My HouseControl project on Github already has the capability (but no users that I know of yet). HouseControl, however has many other features, and needs some configuration, so it would make sense to have a separate server for just FreeTTS.

Could be part of OR as far as hosting the code in OR repository and could be a separate binary download offered on the documentation/wiki page that explains the installation steps, etc.

Posted by juha at May 24, 2013 19:20

Hi Juha, I have had a go at implementing a new protocol for the simple case of running freeTTS within OpenRemote. I have not checked it in yet.

I am wondering how best to test it. I need a controller.xml and panel.xml, with a button and a commmand using the protocol.

The protocol is not yet in the Designer. Do I need to build a new Designer to deploy the protocol XML file? I think you only gave me access to the controller, not the designer in the svn link you sent me.

Is creating the two XML files by hand an option?

I notice there is a test directory for the controller. Should I write a test for the protocol. If so, how do I run the test. A test that just outputs speech may be a bit strange.

Posted by lawrie at May 24, 2013 20:56

Shouldn't be necessary to build a new Designer. Building the necessary commands in XML by yourself is an option. Building the XML as part of tests might be better, but tests should be based on assertions, not speech output, to be useful (tests must be able to succeed or fail in an automated fashion, not by human evaluating them).

It's also ok to post the designer XML here, and I can deploy it on staging server.

Posted by juha at May 25, 2013 04:04

I have checked in the changes for the simple case of local speech generation. I tested it by creating a new test designer account on the demo server, syncing a very simple panel, and then hand editing controller.xml.

Here is the XML for the designer:

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


 OpenRemote, the Home of the Digital Home.
 Copyright 2008-2013, OpenRemote Inc.

 See the contributors.txt file in the distribution for a
 full listing of individual contributors.

 This is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as
 published by the Free Software Foundation; either version 3.0 of
 the License, or (at your option) any later version.

 This software is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of

 You should have received a copy of the GNU General Public
 License along with this software; if not, write to the Free
 Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 02110-1301 USA, or see the FSF site:


 |  Text to Speech using freeTTS protocol configuration for OpenRemote Designer.
 |  Author: Lawrie Griffiths
<openremote xmlns="" xmlns:xsi=""
	xsi:schemaLocation=" protocol.xsd">
	<protocol displayName="Text to Speech" tagName="freeTTS">
		<attr name="text" label="Text">

If this looks OK, could you put it on the staging server.

Posted by lawrie at May 25, 2013 09:36

Should now be available in

Posted by juha at May 25, 2013 13:17

Thanks, that is working. Let me know if you want any changes to the code or configuration that I have committed. I have added a set of freetts jar files to lib, changed build.xml and .classpath to use them, and made the necessary changes to applicationContext.xml. The code consists of the command and command builder classes in a new protocols.freetts package. I create the synthesizer object just once in the commmand builder.

There really needs to be some configuration for the voice and language. I have not experimented with creating extra voices for freeTTS, so I just use the default one called Keven, who speaks English and sounds like Stephen Hawking. I think you need to add extra jar files for different languages and voices, and I don't know how that would be done.

I am not sure if it is worth producing the remote version of text to speech. If people want that, they can always use my HouseControl project.

I would like to follow up doing a rules facade version. I will use the other thread to discuss that.

Posted by lawrie at May 25, 2013 14:47
Document generated by Confluence on Jun 05, 2016 09:30