I dwonloaded the new Pronto firmware into my RU950. The X10 codes that I previously used to dim/bright my lights no longer work. I have tried to revert to the previous firmware version but the installer program will not allow this. This is now a disaster as my whole X10 system is up the creek.

Any suggestions as to potential solutions?

Martin, is this your config file named mjmru950_1.pcf, Because if it is, i found it weird that only two of the buttons in the whole config file had any rf code to be sent in them. Is this whst the problem is? I ask as I never tried your config before prior to this upgrade, But even so a lot of the buttons in it have nothing but 0.5 second delays in them, What gives?

Martin, I have an extensive X10 system and I have full functionality through the 3000 both direct and through various macros with the new software. Perhaps its not an issue associated with the upgrade.

Martin(s) and London,
I have found some quirks since I did the upload a couple days ago.


1: On my Smarthome Switchlincs and Lamplincs, from the "ON" state, it used to take 12 hits of the "DIM" button to shut the light completely off. After the firmware now takes 32. That I could live with, a little more flexibility, and with the improved speed of the macros, took about the same amount of time to go from off to 50% on.

2: I also have an X10 brand wall switch, with this I was able to use 16 hits to go from full on to off. After the firmware, well lets just say I stopped counting after 99 and the light was at maybe 25% on.

I'm using an IR543 and config files from remote central. I've tried the data base codes, on the Pronto itself, and no differance. I've downloaded the config files for both the IR543 and IR543AH, and compared all the IR codes in notepad, and found only the "brite" and "DIM" codes are different. So I tried the codes for the AH model. No help there it just made the dimming more choppy.

I can dim and brighten all of my switches by holding the buttons on the remote, giving me repeating IR. But single presses, like what would be in a macro, are totally out for me now.

I hope some one can help us with these issues, or at least take a look at it for the next firmware revision.

Again, try and use a repeating IR code, by that I mean a button with nothing else but the dim or brite codes and hold the button to see if that works.

I do have single buttons for dim and brighten and holding them down does dim and brighten chosen lamps in a tmely fashion. On the other hand I don't have macros in the 3000 to attempt the same thing. My macros for scene control including dimming are executed by my Smartlinc controller using a single button press via the remote and the IR453. I'll add a dimming macro to my remote and see how it behaves.

I use a repeating code and its works well i.e. holding down the button fully dims or fully brightens in a short time. I also gave the macro approach a try and it goes from full bright to off in 12 steps by linking to the repeating code 12 times. Here are the 2 ir codes I link to:

Dim

0000 006B 0000 000C 00A5 0096 002E 0105 008E 0096 002E 0105 002E 0105 008E 0096 008E 0096 002E 0105 008E 0096 008E 0096 002E 0105 01CA 0DF5

Brighten

0000 006B 0000 000C 00A5 0096 002E 0105 008E 0096 002E 0105 008E 0096 008E 0096 008E 0096 002E 0105 008E 0096 002E 0105 002E 0105 01CA 0DF5

Hope they are of some use.

Joe

These repeating codes don't work on my 7000... the dims are very slow and at the end of say 12 dims, hardly anything dims.

I am using the Pronto direct in RF mode to control X10, and am not using an IR<->X10 converter as this was not needed in Europe (since the Pronto transmits at the right RF frequency; this is only applicable in Europe not in the US due to frequency differences).

With the new firmware upgrade, some of the X10 functionality has been removed i.e. ON/OFF still work OK, but DIM/BRIGHT does not.

I believe that the issue is directly related to the firmward upgrade because:
* Everything worked OK before
* I tried using an older file version created using the last version of the Editor and transferring it to my pronto using the older Editor version - I get the same DIM/BRIGHT problem.

My codes were generated using the CodeGen programme.

The following is the (unsatisfactory) response that I received from Philips today:

Dear Sir,
>
> Thank you for your enquiry.
>
> Please note that the Pronto was not designed to control RF-operated devices. The only RF functionality supported on the Pronto is the communication with the RF extender. We are aware of the fact that the Pronto and X10 RF systems are using the same frequency, and that some degree of control may be achieved because of that. This is considered a lucky workaround, and it was never the purpose of the Pronto design. Therefore we cannot support the direct control of X10 or any other RF-operated devices in any way.
>
> As the new firmware did not change the operating frequency of the RF signals emitted by the Pronto, the hardware or firmware of the Pronto cannot be the cause of control changes. The only possible cause can be the codes used, and these are not created or supported by Philips. I suggest you contact the supplier of the codes or software involved for support on this issue.
>
> Kind regards,
>
> Gerard Feitsma
>
>
> Philips Pronto European helpdesk
>


I accept that they may not directly support X10 functionality, but even if it was a lucky workaround, it did work satisfactorally before, and the new firmware upgrade removed that functionality (one of the main reasons why I, and many other European X10 users, have purchased a Pronto).

Does anybody know how I can revert to the previous firmware version? I have tried using the installer that comes with the previous firmware version but it gives me an error message indicating that I cannot revert to an earlier firmware version.

I confirm that I am seeing the same problems. All my X10 macros stopped working. I tried adding 0.1s delay as prescribed in other threads mentioning this problem to no avail.

A button with a single X10 code associated will work provided it is pressed for about 1 sec, but a simple quick press will not work. This used to work perfectly with Firmware 2.3.12.

I sent feedback to Philips and am waiting for an answer. I would revert my firmware in a cinch if the updater only let me.

Please send feedback to Philips to add pressure and make sure they fix this!!!

I have an x10 appliance module to control my masking system and i had the same problems.

I would use the following code:

3
.1 delay
on
on

i reprogrammed several times but to no avail. I changes the code from the 3 command to 4, adjusted my appliance module accordingly and i am back in business. This is a PITA though, besides this the firmware upgrade has been flawless

The latest response from Phillips:

Thank you for your enquiry.

Alas, as already stated by my colleague, we do not support X10 functionality on Pronto. RF is only integrated for usage with the Pronto remote extender, for no other use whatsoever. We never supported X10 in the past and we do not support it now. It sounds maybe a little bit selfish, but our interest with regard to the RF functionality is only with the remote extender. The new firmware version works fine with it, so ProntoNG's firmware is working properly.

That X10 worked, was for some people a nice coincidence. However, for us it was never a way to promote Pronto, because we always stated that X10 was officially not supported. Workarounds by customers or 3rd parties cannot be supported by us, nor can they demand us to provide support for something we do not support.

It is not possible to downgrade your ProntoNG with a previous firmware version, so you have to use the latest one instead.

Kind regards,
Vincent Pfeil

Philips Pronto/URC European helpdesk


This is still a totally unsatisfactory situation. After all none of my codes have changed - only the firmware - hence I believe that there is a serious error in the code that Phillips refuse to accept (unless any respondents have an alternative suggestion?). Also I do not understand why Phillips cannot enable the installer to allow reversion to an earlier firmware release.

Any suggestions?

From the codes Martin emailed to me, it appears there is a problem in the editor or firmware. I only have a TS1000 to which I added a 310MHz RF transmitter so I have no experience with the new editor or the NG firmware.

It appears to be recognizing some of the X-10 codes as NEC1 but then screws up the translation. All of the X-10 RF codes are NEC1 but sent as 310MHz or 433MHz RF depending on locale.

Can someone give me a succinct explanation of the 900B notation? Specifically, 900B 006D 0001 06F919E6 which is the (mis)translation of the "A DIM" RF code.

What is the third word, 0001?

The first two bytes of the code (06F9) are correct but the bit order is reversed from the way I would write them - this may be the way Philips stores them. The final two bytes (19E6) should be 8877 or 7788 depending on bit order.

Anyone contacting Philips about this should probably not mention X-10 RF and just complain that NEC1 codes are being screwed up by the new firmware or editor. An NEC1 code is an NEC1 code regardless of its target.

Just to be clear, I am not using the RF functionality (I am in the US) but rather X10's IR543 Ir converter, so this should just work like another Ir equipment.

I think I know, how to fake the updater in order to flash older firmware:
Updater obtains the firmware segments versions from Pronto and compares those (versions) with ones stored on the end of tspupd.exe.

1. Run Update_Pronto_NG.exe from TSU3000__v2.3.9.zip or RU950__v2.3.9.zip and don't touch it.
2. Go to "C:\Documents and Settings\###current user###\Local Settings\Temp\IXP000.TMP\"
3. Copy both files (tspcom.dll and tspupd.dll) to stable place, say "My Documents\NG recovery"
4. Carefully, byte-to-byte, change both strings at the end of tspupd.exe "2.3.9.0" to "3.2.0.0"
5. Close Update_Pronto_NG.exe, use tspupd.exe.

After the updating, Pronto become actually 2.3.9.0, de-facto and for updaters.

If it is actually, I can write the masquerader. But I hope for discretion at all: Pronto IR/RF capacities can’t become worse permanently, once they will be cured :)

Why do these repeating codes may not work now? Let’s try to increase the last byte 0DF5.

Well, Eigeny you are a genius! I am now back in business with 2.3.12, granted, it sucks batteries and has slow macros, but who cares about fast macro playback when only 1/2 the commands work?

Now waiting for a fix for 3.1.15...

You got me out of the ditch, Spaciba!