This page last changed on Oct 20, 2013 by ptruman.

Lo all

Slowly been plugging my devices into OR today, and have some thoughts/requests :

1) One request immediately leaps to mind - can we have a TCP/IP sender which "fires and forgets" and does not wait for responses? (as well as one that does)

The reason for asking is I've been setting up my Onkyo Amp, and was playing with DLNA. I found the cursor controls (up/down) REALLY slow, but via Hercules or another telnet client, they were lightning. I can only presume this is due to the amount of crap that the Onkyo fires back at OR after it sends the command. "Telnet" has a read timeout, but TCP/IP doesn't, and that might solve the problem if set to "0"?

2) Could we have commands issued from the tab bar? I'd love to have a global mute, but currently have to add a button to each screen.

3) Would it be possible to have sensors that ONLY fired when you were on a certain screen(s)/group?
There is no point in my querying my Onkyo for track info unless I'm on my DLNA control page - so a "selective" sensor would be really cool, and also cut down LAN traffic.

Still, the more I have running today I am more impressed. I shall post some pics later

Also, I've found that I can drive my PS3 (Slim) via my Onkyo, and thus via OR. If anyone wants details, let me know. It's all via HDMI

1) OR commands are designed such that they don't return a status. However, protocol implementation e.g. telnet might need a couple of request-reponse cycle to perform desired task.

2) Which tab bar are you referring to? You can design a button which executes a macro for global mute.

3) OR is designed to accommodate a variety of devices. Some devices might have a hardware switches in addition to IP control. In such cases, OR can only know the current state of the device by polling it. Hence, sensor polling happens at regular intervals in the background.

Posted by atamariya at Oct 21, 2013 06:01

1) They don't return a "status" but they DO accept the output from the connected device (as that's why you use REGEX, to parse the result). If the result is "large" (try browsing a DNLA folder full of MP3s....) it slows down OR. Connecting/sending and DISCARDING the output could potentially alleviate that. (but in no way am I suggesting the existing method should be withdrawn, as it's vital - this is just a request for optional discarding)

2) Android devices have a "tab bar" - pressing the Android menu button brings it up - but any buttons on the tab can only allow you to "login/settings/back" etc, or go to a screen. I can't see macro calls.

3) I know - but I'm asking if (as per 1) we could have the option such that they only fire whilst a device specific screen is displayed/accessed. In some cases, device states are irrelevant unless they are actively "in use". Right now for example, my A/V receiver is off, so I don't need it to be telling me the volume is set to 0 and no station/input is active.

Whilst I'm thinking about it : master/slave sensors would also be really cool. Philips Hue devices for example return "ALL" info for every bulb in one URI request, but if I want to get multiple settings for multiple bulbs, I need to write multiple sensors. If I could make one request, and then use the results from that to populate multiple sensors, it would be considerably more efficient.

Similar to my (3) request above - conditional sensors could also act "in order", i.e. IF my A/V receiver reports it is On, then run the other sensors which are specific to that device. Otherwise "hold" them.

So far I now have iTach (IR), LightWaveRF, Philips Hue, TCP/IP & UDP all operating, with some devices "chained" (i.e. I'm using OR to drive my A/V receiver to drive my PS3).

Posted by ptruman at Oct 21, 2013 08:03

1) One request immediately leaps to mind - can we have a TCP/IP sender which "fires and forgets" and does not wait for responses? (as well as one that does)

The reason for asking is I've been setting up my Onkyo Amp, and was playing with DLNA. I found the cursor controls (up/down) REALLY slow, but via Hercules or another telnet client, they were lightning. I can only presume this is due to the amount of crap that the Onkyo fires back at OR after it sends the command. "Telnet" has a read timeout, but TCP/IP doesn't, and that might solve the problem if set to "0"?

This should be a fairly trivial change to the implementation. I do not have the time to address it right now. Would welcome a patch from community if anyone wants to tackle this. Otherwise will keep it on the list of wanted features and address it later.

Thanks for the suggestion,

– Juha

Posted by juha at Oct 25, 2013 11:00

2) Android devices have a "tab bar" - pressing the Android menu button brings it up - but any buttons on the tab can only allow you to "login/settings/back" etc, or go to a screen. I can't see macro calls.

Good point, and I'm actually surprised that it's missing. I will need to check with Eric what's the deal with that.

Posted by juha at Oct 25, 2013 11:04

I'd have a go if I could code in Java :\

Rather than code a "whole new" TCP/IP or Telnet variant, it may be easier to put a logic IF statement in that if there is no REGEX statement present, then simply fire & forget (or discard) the incoming data. However, I suppose that might break anyone who has custom rules code setup?

Posted by ptruman at Oct 25, 2013 11:16

I'd have a go if I could code in Java :\

Yeah, there's another thing I have an idea for a fix but no time to implement. Maybe we will get there.

Posted by juha at Oct 25, 2013 11:19
Document generated by Confluence on Jun 05, 2016 09:30