Wow! If that isn't the weirdest thing. I made the same change, moving my two RFX9400s and one RFX9600 from hardcoded IP addresses to DHCP. At least with a one hour trial, the Command Failed and error 450 problems seem to have gone away completely.

Add complexity and a new point of failure (DHCP), and the Pronto network support gets better. Go figure.

Ganymebe - are you using WEP or WPA?

Very odd that switching to DHCP solves the problem. My testing from the simulator to the RFX9600 showed no failures at all, but from the TSU9600 to RFX9600 it always occured.

Did you actually change the RFX's to DHCP addresses or just tell the remote that they were DHCP? I'm going to try the latter before actually making the RFX DHCP.

Well, if from simulator, all is well and PC is on wired network, there may be other issues at play.

The above seems to indicate to me that the problem "might not" be with the Philips implementation, but "maybe" from other wireless interference in the install. Several have posted comments about a tool wifispy or wifi-spy for finding exactly how much interference/steady signal is present on the channel you are using. May be that switching to another channel might help the issue.

I use WEP. I was actually waiting for the Pronto to add support for WPA and when they did, it had fallen off my mental list.

When I switched the RFX to use DHCP, it rebooted with a different IP address.

More as I discover it...

The PC controlling the RFX9600 is also wireless.

I had thought the interference could be an issue as well, but I have an Intel app that shows all the channels on the local WAP's as does the Tomato software running on the Linksys. The Linksys even does a full site survey and chooses the best channel. I use channel 2 and there is one AP on channel 5 and a handful all on channel 11.

I have tried, when picking up my tsu9600/9400 from sleep and first press a weather app (all over ip, noextender involved) to check whether the pronto is really logged on, whcih it was, and then press a key with something that goes over an extender, the first button press resulted in Command Failed, thats how I concluded that the error might be in the extender software. As there are few parameters to alter, changing to DHCP was a given try, and it worked after that. All this has been documented and sent to the Prontoteam, they are working on it.

I also sent my information to the Prontoteam email yesterday.

Also, I find that adding links to posts on these sites to my emails can help to give context to the ProntoTeam as they sometimes miss threads that pop up here/there in this forum.

Lyndel

I have exactly the same problem since WAP integretion with a TSU9600 and a rfx9600.
I was not even using WEP or WAP since I don't have any close neighbours. No problems with the Wifi or cabling.
Using only fixed IP's so I will try DHCP tonight.

/Harry

I have now tried setting the extender to DHCP and it all works fine every single time.

I also looked in the help file and found following sentence:

"Extenders preferably use DHCP instead of fixed IP addresses."
So the issue might be known by Philips.

Regards
Harry

These will only show WiFi devices, not other sources of 2.4GHz radio emissions.

In my experience, interference from non-WiFi sources is much more of a problem than interference from other access points.

Happy to report that the job I was having this issue with has had it's extended changed to DHCP and no more initial command failed problems!

I found, like Nimnul did, that a macro that contained IP based communication to AMX and commands to an extender would send the AMX code fine but loose the extender command.

Kevin D.

I finally got around to changing my RFX9600 to DHCP last night. Over the course of about 3 hours, I still had 1 "Command Failed" message, where normally I would have had about a dozen in that time frame. In addition, a quick repress of the button was processed quickly meaning that the time necessary to reconnect was far less.

• When user picks up remote, connection with wireless network may or may not exist. Network Status Icon will show either WiFi strength, question mark (no identification), or red X (no connection).
• Will get a Command Failed reply when Network Status Icon is red X or question mark. But will sometimes happen even when Network Status Icon shows WiFi strength -- will often get a Command Failed response to button press that requires wireless communication to RFX9600. Network Status Icon then updates to red X (no connection).
• After behavior above; connection is usually established within 20 seconds, but sometimes will require TSU9400 to be switched off/on.
• Once a connection is established (confirmed by Network Status Icon and a wireless command successfully sent), TSU9400 will stay connected with no issues. Eventually backlight will timeout making it impossible to determine connection status at TSU9400.
• Checking TSU9400 display status against wireless connectivity status of TSU9400 MAC address at the router:
  • Wireless connection is stable until TSU 9400 LCD backlight times out, then connection dropped until backlight is on again.
  • This varies with the timeout setting (Settings 1 tab within the System Properties folder). Consistent behavior whether the timeout is set to 15 seconds, 30 seconds, 120 seconds, 240 seconds. Wireless connection dropped when backlight times out.
  • Note: No difference in connectivity if running WPA-2/AES Cipher or WPA/TKIP Cipher
  • Minor (off topic) observation: Key backlight timeout does not function independent from LCD backlight timeout. If I set the LCD timeout to 120 seconds and the Key backlight timeout to 240 seconds, the key backlight times out at 120 seconds.
  • All of this happens in spite of the Pronto wireless timeout set at 24 hours.

• TSU9400 Firmware: 7.2.22. IR Firmware: 4.0.20 (latest version)
• RFX9600 Firmware: 1.4.5 (latest version)

• Network Options: Wireless
• Wireless Timeout: 24 hours
  • Add Extenders:
    • Extender #2: Serial Extender (RFX9600)
      • No fixed IP (DHCP Reservation instead)
• Use Control Panel: With Wireless & Serial Extenders
  • Advanced WiFi:
    • Single Access Point
    • WiFi Channel: Specific channel 9
• WiFi Settings:
  • SSID: name input
  • Encryption: WPA
  • Passphrase: passphrase input
• IP Settings:
  • DHCP

• LCD Backlight Settings
  • Brightness: Level 3
  • Timeout: 240 seconds
• Key Backlight Settings
  • Timeout: 240 seconds
• Volume Settings
  • Button Volume: Level 1
  • General Volume: Level 1

• Time Settings
  • Time Zone: GMT -8:00 Pacific US
  • Timeout: AM/PM
  • Day Light Saving Time: On
• Other Settings
  • Pickup Sensor: On
  • Language: English
  • Animation Mode: None
  • Firm Key Behavior: Turn Display On Only
  • Cursor Key Behavior: Turn Display On Only

• 802.11g only
• Single channel 9
• SSID Visible status
• WPA-personal security
• WPA-2; AES Cipher
• Group Key Interval update: 3600 seconds
• WLAN Partition: Disabled
• WMM: Enabled
• Short GI: Enabled
• Extra Wireless Protection: Disabled

• Pronto TSU9400: DHCP Reservation set (dedicated IP address). Not sure how this is different than a fixed IP other than the fact that the router assigns the IP instead of the administrator). Seems to perform the same whether I use DHCP Reservation or assign a dedicated IP address.
• Pronto RFX9600: DHCP Reservation set (dedicated IP address).
• UPnP:  Enabled
• Multicast Streams:  Enabled
• Wireless Intelligent Stream Handling:  Disabled
• No Port Forwarding rules established

I have seen this befor with Passphrase, change the Passphrase to a HEX Key, and try again.

Also using a N type Wireless AP , if you set it to G only and try it is it any better?