For anyone interested, there is an effort to port Pronto Pro to OpenRemote beginning. [Link: openremote.org].

Help with the schema and IP Protocol, and other details would be welcomed.

Page not found.

www.openremote.org/display/forums/PRONTO+port.

is there any true sense to enable the RFX9600 in this open thing as it is, for now, a dead device?

I was never really fond of the RFX9600 beacuse of it's limitations (one thing at a time, only has 3 true RS-232 ports) and it's disadvantages . uses UDP to communicate with the TSU's which is a really inreliable protocol and should not be used for critical applications (which home control in my eyes is).

sWORDs on openremote.org said...

The way the RFX communicates over UDP is pretty solid, messages are repeated several times until a confirmation is received. So it might give some overhead, but should be reliable on a decent network.

But arent the GC's better, they sure are cheaper for the same thing.

Again, as Lyndel mentioned several times the RFX has only 3 true RS-232 ports. ports 3 and 4 are basically the same port. The RFX can't buffer a thing. True you could buffer on the remote, but would be a lot of work, you would have to make a dynamic buffer that would know what to do, example:

You are on a page with DVD icons, you press a couple of buttons and the remote stars sending those codes. You have a buffer, so all things get done. Then you exit the DVD page, but the buffer still has not finished what it was doing before so it would continue to try to send the data. But by now you're trying to do something different, let's say open the front door ... but your buffer is still trying to operate the DVD. In this case you would need to flush the buffer and insert the open door thing (let's say you do it with a relay) or make an intterupt buffer call to process the door. I never figured ot if it is the extender that signals that it is busy doing something or if it's a TSU that figures it out somehow.

I know the RFX repeats the messages but i don't remember it waiting for confirmation (have to check the coms again tomorrow). To tell the truth I never quite understood why philips chose this way of communication. Sure TCP has some more overhead compared to UDP ... but when you send the same UDP message 3 times ... well it obviously generates more overhead without actually improving the communication. UDP simply was not designed with reliable communication in mind.

Don't get me wrong, if you really want to do it go ahead it's always good when someone does something useful.

But i'm wondering if it is worth to put a new saddle on a dead expensive horse.

BluPhenix,

I think this is not entirely accurate. The RFX9600 communication protocol does provide quite efficient buffering as long as the PS/feedback is not used (I am unable to play with 2-way since I only have tsu9300). The transport protocol built on top of UDP allows payloads that contain entire macros consisting of Serial/Relay commands, delay actions and power sense based conditional execution.

As a result if all the steps in the macro target the same device, multi-step macros are compressed by the PEP into one execution request that gets sent to the extender as a single payload message. If there are no retries then regardless of the length of the macro (within reasonable limits, of course) it results in just 3 datagrams (initiating the conversation, request to execute, ending the conversation) sent to the extender and only 4 short datagrams returned from the extender.

I don’t think GC can do delays or conditional execution – it all needs to be done by the controlling application explicitly.

...

Added:

Correction - actually, the commands don't even need to target the same device - as long as it's the same extender, everything gets nicely packaged, delivered and then executed in one shot. I've just tried a mixture of IR, Serial, Relay, conditional execution with Power Sense and also delays added to a macro and observed the same pattern.

|

I'm globally queuing many commands, particularly power and input selection. I can delay a command execution if necessary. Out of order execution is allowed. (this is a mixed blessing by the way) If one jumps to a different activity, the queue follows and continues to execute. In many cases this gives the feel of a much faster program and observant users of previous programs can be spooked by a command that is emitted some seconds later. While this is a great feature to support those slow TV sets that may require 10 seconds to get their heads on straight before accepting an input command, the user must still take care because during IR transmissions all button presses are acknowledged, but thrown away. scheduleAction() would seem to be a way around this, but the jump out of an activity is held up until the last scheduled IR command is executed.

Currently, I don't have a flush the queue function, but it would be easy to add. The clear function would need to be carefully used, however, because I could lose track of the current state.

tengzik, yes but the RFX always returns the response 3 times, so the TSU gets it. With TCP it would not need to send more than once unless required.

In my experience the pronto communication protocol doesn't provide any buffering. The RFX per se is really a dumb device. It gets a command from a TSU and reports back how the execution went. Nothing more. If you try to make it do something else in the mean time it will fail. If the RFX is executing a IR code send and in the same time it receives an RS-232 task from the TSU, it will fail.

I was on the verge of making my own "RFX" device, because it costs quite a lot of money for what it can do, but since the Pronto reached the end of it's life it is not an option any more.

I don't know what GC can actually do. But neither the RFX can do any delays or conditional execution, all is done by the TSU.

EDIT: Now i figured it out you meant the delays in the IR macros, those it can do, which is obvious.

It doesn't matter if the RFX buffers or not. The controller or remote is perfectly capable of buffering and queueing. And yes it does buffer, but it does not queue. And the buffers are emptied on a new command.

It doesn't matter that the GC devices are better or not. If the RFX is good enough it could save money and effort for those that already own a RFX. If Pronto trully ends, there won't be new RFX devices after this month anyway

And the RFX doesn't respond three times on everything it also can't do delay's, it seems as if the TSU does the delays.

Ok we're mixing the meaning of the words here now.

Yes it buffers data, but it does not buffer commands.

tengizk said that is you send a macro, the TSU all packs it into one datagram and sends it to the RFX, therefore the RFX must be able to male delays in the execution of the IR sends (a very trivial thing in microcontrollers).

Ok to reuse the RFX in case you TSU dies is an option I have not thought of.

As far as I can see ([Link: remotecentral.com] RS232 commands it does pack macro's in a single UDP packet, but there are no delay's. Which is weird, because you can give power on an a between command delay in PEP.

Left u a message there.

I believe you meant with IR macros. I doubt it has the capability of registering multiple rs-232 commands and executing them in series.

No I ment RS232 macro's. Still haven't looked at IR. Start with relay's then moved to RS232 (still need to look at RS232 requests). IR is last on my list.

Hm than this is something new. I'll have a look at it, i'll report.