Migrate OPII setup to Omni IIe?

[pct88]

I have an HAI OPII f/w 3.0 whose ethernet port has failed.  I defaulted the EEPROM and RAM and still can't ping or connect via IP.  I brought in an Omni IIe f/w 3.11c and it works fine on the same ethernet.  So I want to migrate the configuration and automation from the OPII to the Omni IIe, swap it in to the cabinet and ship off the OPII for repair.
 
Question-  I have tried various combinations of exporting, importing and Dealer PC Access "Version Override" without luck moving the configuration.  I was told I will have to re-enter all of the configuration by hand.  Before I take on that task does anyone have suggestions to simplify the process?  
 
I was able to copy/paste the 150 line of automation from one to the other, but I am not sure that the variable names will properly match up even if I duplicate them with matching case and such?
 
Yes, I realize that the Russound control won't function on the IIe.
 
Any suggestions will be appreciated!
 
 

 

[HAI_fjh]

The challenge with this type of migration is that the OmniPro II has greater capacities and features (like Russound) than the Omni IIe. For this reason there is no automatic migration. You will have to recreate the configuration in the IIe. My recommendation would be to print your Pro II account file then referring to the printed document, enter the setup items in the new IIe account file.

You will need to make note of Items that can not be configured in the IIe. Things like user codes above 16, or units above 64, etc. You will have to figure out how you will resolve these problems.

As you have already figured out you can open one account file, copy the automation blocks, open the other file then paste the automation blocks. The problems you will have to watch out for are the same things mentioned above. If on the Pro 2, zone 10 was the front door and unit 2 was the foyer light, and you used the same zone and unit numbers in the IIe file, automation like turning on the foyer light when the front door opens will still work. This works because although PC Access shows you lists of zones and units by name, when you pick something only the zone or unit number is stored. From the controllers perspective it sees when zone 10 not ready turn on unit 2. So if in the Pro II unit 75 was "Foyer Light" but in in the IIe unit 2 is named "Foyer Light" the automation will not work as expected.

These sort of problems can not be resolved automatically.

If you are getting the Pro II repaired you might just want to wait. This is where a good dealer can really help. Many carry spare boards in stock and can just swap it out to get you running again the same day. Even if you are a DIYer you might want to contact a local dealer and get them to do the swap. It may cost a few bucks, but your time is also worth something.

This is just a suggestion but may save a lot of aggravation.

 

[pct88]

Fred-
 
Thanks for the pointers.  The configuration is migrating OK except for the unit numbers as expected.  This panel has a mixture of X-10 and UPB modules.  Unfortunately the UPB device numbering was started at 200 and up from there; the Omni 2e is limited to 64, so I have to re-configure all of the UPB devices and associated programming lines before I can proceed.  It is all a good opportunity to clean up the programming, remove outdated devices, etc...
 
I sure hope HAI/Leviton will be able to fix the OPII on the first try; it seems to have a variety of issues including lack of ethernet communications and serial bus issues.  Following a recent alarm activation the entry keypad would not reset the system until each digit was entered many seconds apart.  Even after disarming at that keypad, the master bedroom keypad remained in audible alarm status for a couple of minutes before it reset.  Very annoying!

 

[pct88]

I swapped the Omni 2e board in for the OPII after updating the automation code to use device numbers and such that fit within the constraints of the 2e as compared to the OPII.  So far I am very happy with the results-  the ethernet port is working nicely again with very acceptable network performance.
 
Next I plan to factory default the OPII again and confirm that the ethernet still is not working before shipping it in for repair.
 
I can't help but wonder if it would be possible to shift ALL of the socketed chips from the OPII with the non-working ethernet over to the working Omni 2e and get the full OPII functionality?  The two boards appear to have the same components other than the socketed chips.  It would also make sense for manufacturing and stock management purposes to use a common board for the various different models.

 

[HAI_fjh]

The two boards are very similar and do share many components, but not all. You can try it, but it will not work.

 

[ano]

I'm going to go in a different direction.  Did the Ethernet port REALLY fail?  A "dead" Ethernet port is the symptom of a bug in your programming. Before you replace anything, clear your program (using a console) and see if it fixes itself.

 

[pct88]

Before swapping to the Omni 2e I indeed defaulted both the RAM and configuration from the console and confirmed that I still had no IP communications.  I also disconnected all the thermostats, serial ports, X10 and keypads to confirm that they were not causing the problem.  I even tried changing the IP address and connecting directly with a crossover cable and manual IP config on a PC to remove the network as a possible cause.
 
The Omni 2e board I swapped in has been running fine with the same programming: although re-typed and with some shifted device addresses due to differences between the panels.  No sign of any of the problems I had been seeing.  No Russound control though.
 
Before shipping the board out for repair my final test will be to confirm whether IP communications is working with ONLY power and a single keypad connected and the original programming.  If not I will then default the panel and test IP again.  I am also confirming the IP address at the keypad of course.
 
Any other suggested checks before I invest $200+s/h to get it repaired?
 
Thanks

 

[pete_c]

Here no real suggestions but rather watching your posts.
 
I have a different issue and it involves network, time and an Omnistat2 issue relating to comm on my OmniPro 2 board.
 
Historically my time would go off sync, Omnistat2 would start to get comm errors then the network connectivity would be poor with odd drop outs but I could still aways connect via the network.
 
Over the last couple of years the issue was very intermittent.  I saw it happen for the first time after installation of the Omnistat2 replacing the RC80 which had worked fine for many years (with both the legacy OPII board and a couple of years with the newer OPII board).
 
My "mickey mouse" fix would be to disconnect the network cable for 1-2 days; reconnect it and all would be fine for months.
 
Recently when updating to FW version 3.11C the issue cropped up again.  Only this time the temporary for one or two days disconnect of the network cable did not fix my issue.
 
To date I have only cleared the programming lines but not anything else.  I have reset both Eprom/RAM a few times but have reloaded my configuration each time. 
 
I may try what you have done if the problem continues. 
 
IE: reset EEPro, RAM and update to current FW.  Install a new non configured setup and disconnect all of my serial devices.  If that works then just manually reconfigure everything from scratch.
 
I did upgrade my OPII board a few years ago and it was a PITA but not too difficult.  I was more apprehensive about doing the board swap more than anything. 

 

[pct88]

After swapping the O2e in I just tested the OPII that I removed and the IP connection appears to have started working again. Grrr...  I am a bit hesitant to pay $200 for repair of an intermittent problem...  I have both the old and new panels talking to Haiku Helper now; I'll be watching to see if either run into IP connection issues.  The O2e I swapped in is connected to exactly the same sensors, serial and IP devices that had been hooked to the OPII and has been working without incident for a week now.  So why is that one working when the OPII did not?
 
The only difference is that I had to re-load the programming and shuffle around some of the addresses due to differences in the panels.  But that doesn't explain the OPII IP problems even when I had deleted all configuration and just entered an IP address to test without luck.
 
Perhaps it takes time before the problem recurrs-  I will leave it running for a while and keep monitoring the operation.  I will also hold off on returning the OPII until I have a more definitive failure.