This page last changed on Jun 08, 2011 by kurrazyman.

Just want to see if there is any interest in this functionality.

It is something I know I would really like to see, I have done some personal protocol development for my projects and have then had to manually edit the controller.xml files to add in additional protocol properties that I couldn't add in the Online Designer, for protocols that aren't in the online designer at all I often resort to using pseudo names in the Online Designer and using a text editor to do a mass replace.

This would have saved me a lot of time, fudging things and I think it is the one area that limits user's freedom to tinker with protocols.

Please add your opinions/ideas.


I would really like this! I have been working with the connection manager branch. I need to set the scriptfile property. It is just unworkable constantly having to edit the comtroller.xml file.

I have been working on a hack to allow me to specify a script file in the command value property. Its a bit slow going as I am finding my way through the code at the moment!

Ideally a facility in the Online Designer to add property/value pairs would be much better.

Let me know if I can help out.

Posted by mandp at Jun 09, 2011 19:51

Hi Mat,

I know your pain when it comes to editing the controller.xml; especially as there is no way to easily identify commands within the xml structure and the command IDs can quite easily change once you make a change in the Designer.


Posted by kurrazyman at Jun 09, 2011 20:42

So briefly this was my short term plan:

For the Telnet protocol if the command is of the form

null|?V${script test.js(word=VOL)}

the "null|?V" is passed on as the command as usual. test.js is added to the script engine and word=VOL added as an arg.

I have nearly finished a rather untidy implementation to see if the idea works.

However, (unless I am going completely mad) on there are fields for Readtimeout, read regex, group and default response. These look useful but I don't think they are implemented on the gateway feature branch. Is that correct? If so can we merge the gateway function and the regex function in to one for telnet? I think I could use this instead and it would be much easier to use (as you would not need to write java script).

Posted by mandp at Jun 10, 2011 00:49

Hi Mat,

Juha hasn't long uploaded new telnet.xml and new udp.xml protocol definition files to the Designer hence why you have seen the new parameters for the telnet command.

The parameters that have been added work with the telnet read implementation I put together a few months back; this has now been merged into the trunk so the latest controller supports those telnet commands parameters.

You're right in saying that the Connection Manager branch doesn't support those commands and instead offers the scripting option to apply a regex filter and more.

If the simple regex filter would meet your needs then I'd work with the main controller rather than my connection manager branch (depends on whether or not it is an issue for you that the main controller connects and disconnects to the server for each sensor poll independently whereas the connection manager makes one connection and all polling is done through that one connection).

The future of the Connection Manager branch is sketchy at best so if you want something more predictable then stick with the main controller I'd say.


Posted by kurrazyman at Jun 10, 2011 14:14

Yes, i see. Unfortunately my Pioneer AV amp only accepts one connection at a time so it looks like the Connection Manager is the best route for me. However, I will consider how I could get back on to the main controller. Rather than split off, it sounds better for the future. Am I the only one with a need for the connection manager?

Thanks. This is such a great project!

Posted by mandp at Jun 11, 2011 08:44

The reason I created the Connection Manager branch is for the exact reason you describe, I was connecting to a PulseAudio telnet server and it doesn't seem to like too many simultaneous connections. Didn't notice any issues until I had few sensors that used that server and as each sensor in the main code branch creates its' own connection thread the sensors were crossing over each other and polling attempts were failing.

So you're definitely not the only one with this problem as lots of equipment only wants a single connection at a time (KNX IP Interfaces are one), the un-certainty is how the connection manager will be implemented in the main branch, there are a lot of changes to the code I wrote (XML schema, removal of polling threads, etc.) so legacy support needs to be a consideration.

Juha needs to/will drive this and I know he has ideas/plans for the next iteration of the controller.


Posted by kurrazyman at Jun 11, 2011 09:28
Document generated by Confluence on Jun 05, 2016 09:32