import xml file error - perhaps it is not a valid ISY export

[taskman]

Hi,

 

Getting this error regardless of which account an xml file is attempted on.

 

Any suggestions?

 

Thanks

[jsf]

Hi,

 

Getting this error regardless of which account an xml file is attempted on.

 

Any suggestions?

 

Thanks

 

Hi,

I have a fairly good idea of what your problem is. In another post of yours you mentioned you had a total of 271 devices in your ISY (or perhaps it was devices plus scenes). Now, the instant you add a new device OR scene to the ISY, the ISY automatically assigned an ELK address to it. The ELK has a 256 address spaced (modeled after X10), A1/A16->P1/P16. So, if you have added more than 256 devices/scenes (an 8 button KPL counts as EIGHT devices/address spaces for elk purposes, just as a remotelinc counts as 6 elk devices/address spaces and motion sensors count as 3 etc), your xml file will exceed the 256 limit and start assigning addresses beyond P16. Since the elk addresses are assigned at the time the device/scene is added to the ISY, simply editing the elk xml file to remove devices will not necessary solve your problem, as any device past #256 added to the isy would have an illegal address space as seen by the elk (q01, r01 etc). The only way around this at the moment is to actually remove enough devices from your isy to get below 256 and then re-add back the devices you want to use in the elk. Furthermore, if you pass the 256 space again (with devices that you don't care to use in the elk), you MUST edit the xml file so as to remove any items that are addressed beyond P16. In my case, I actually had to replace many of my 8 button KPL with simple switchlincs as seven-8 button KPLs count as a whopping 56 elk devices. Universal devices is aware of this issue and I have personally spoken to Michel about it. I don't know how many people out their are using elk/isy configs, but if there are enough who are in the shoes of more than 256 devices, speak up so perhaps the priority of this can be increased. Personally, I'm also looking forward to the day of much increased elk integration even if it means purchasing a paid module so that we can create isy programs based on elk conditions/status/alerts etc, as the programming capabilities are much stronger in isy than elk (not to mention elk's severely limited memory.

 

P.S. If I'm mistaken about any of the above, please do not hesitate to correct my observations

[taskman]

Hi,

 

Very good and accurate response. That is exactly what was done. Removed some devices and added the ones needed in Elk, then export, then add back the others.

 

The silly part is this is an easy fix. The export should first display a manage page with checkboxes to the left of each device. Default can be that they are all checked and the export button at the bottom can only be active (IF) devices < 257. We are talking about a couple hours of programming if that.

The devices page is already completed. Sarting with a copy of that and adding some mods. Couple hours tops.

 

Thanks

[Michel Kohanim]

Hello jsf,

 

Thanks so very much for the detailed response and you are 100% accurate. We are completely aware of this issue and it has medium priority. So, it shall be implemented shortly.

 

With kind regards,

Michel

[taskman]

Hi,

 

Complaints are like cockroaches, when you know of one, there are another 10 - 100 you don't know about. Most will just go elsewhere. Many that use a product may not necessarily reccomend it. The old question "if you were to do it over again".

 

There is a reason companies want to know the answer to that "key" question. It eliminates being in it due to time and/or money invested.

 

Proactive vs Reactive

 

Nightly builds = concerned and proactive oriented.

Nightly builds for fixes not add-ons

[Michel Kohanim]

taskman,

 

For your information, ELK/ISY users comprise less than 3% of our total sales for the past 2 years. Just like any other normal company, we assign priorities to requirements and the main factor is ROI. Very simple.

 

With kind regards,

Michel

[jsf]

Hi,

 

Very good and accurate response. That is exactly what was done. Removed some devices and added the ones needed in Elk, then export, then add back the others.

 

The silly part is this is an easy fix. The export should first display a manage page with checkboxes to the left of each device. Default can be that they are all checked and the export button at the bottom can only be active (IF) devices < 257. We are talking about a couple hours of programming if that.

The devices page is already completed. Sarting with a copy of that and adding some mods. Couple hours tops.

 

Thanks

 

I actually don't think it is that easy based on the way the isy currently handles elk addresses. The elk address assigned by the ISY is not given at the time of xml file generation, but at the time it is initially added to the isy, thus a checkbox at xml file creation time is not the solution here. The other issue is that you do not want a dynamically generated address to the elk as each time you make even a small change to something in the isy and generate an xml file for elk, the dynamically assigned addresses would be completely different than previously and thus completely destroying any setup you may have had in the elk. I'm not sure what the solution is here, but perhaps the ability to assign static elk (x10 style) addresses to each device in the isy (with isy checking to make sure no other device is occupying that address space when the xml file is generated). The other HUGE advantage of going the static route is that you could order all lighting as you wish and not have all lighting randomly assigned and thus all over the place in the elk.

 

Just some a few more cents from me...

 

Now, if only Cortexa and Universal Devices could get together and create an insteon gateway/plugin for the Cortexa.

[Michel Kohanim]

jsf,

 

You are 100% correct: the only solution is assign static addresses. Any new nodes, will get their default address (A1 to P15) if and only if that address has not already been taken through the static means. We shall have a GUI which lets you assign different addresses to different nodes.

 

The major drawback of this solution is that, now, every interaction between ELK/ISY has to go through a node address translation routine which might have a little performance impact especially if you have a lot of devices.

 

Above and beyond major regression testing, I think we should be OK.

 

Thanks again and with kind regards,

Michel

[MikeB]

Now, if only Cortexa and Universal Devices could get together and create an insteon gateway/plugin for the Cortexa.

 

I spoke with someone from Cortexa at the last EHX, and they seem interested - we're ready to assist whenever they are ready to go.

[Baypointe]

Elk/ISY 256 device limit

 

I am having the same trouble as what is described here. My system has 50 addesss over the 256 limit and removing them with all of the links/programs seems like a overwhelming task to get the lighting going.The last post was a long time ago and I was hoping that something has been updated on this. I had not read this thread and just sold two systems and upgraded my alarm system with Elk/ISY intregreation.

 

Is there any update or something else I can do?

 

Thanks

Jim

[Michel Kohanim]

Hi Jim,

 

We are working on an ELK module which should alleviate some of these issues. Unfortunately, due to lack of time/resources, it is taking us longer than anticipated.

 

With kind regards,

Michel