HOME › Forums › Gateways › EZSrve › 2.0 Beta+ Released

Viewing 15 posts - 16 through 30 (of 35 total)
Previous 1 2 3 Next
  • Author
    Posts
  • Anonymous
    Inactive
    April 28, 2009 at 1:14 am
    Post count: 1001
    #42672

    Sorry if mine was not humorous, it was meant to be. I ran with the Beta+ and am running with Beta+1. I found an X10 problem with the Beta+ which SHN fixed very quickly (which is why I thought they would release another Beta+ image quickly). The first user to try Beta+ (at least the first to post back results) was using FireFox 3.0.8 which was causing xml file upload problems. When he tried to go back to 1.60 (something which SHN had test successfully) the image did not get uploaded correctly. Shortly after that Simplehome posted information that IE should be used and DHCP (rather than a static IP) should be used for uploads. I assume they were from the results of analyzing the upload of 1.60 from a Beta+ environment.

    Anyway, I think SHN is testing the various combinations to be sure there are no image upload problems with the next Beta+ image. We will just have to wait for that event to happen. Has given me time to do much needed yard work.

    Anonymous
    Inactive
    May 13, 2009 at 10:23 pm
    Post count: 8
    #42673

    Not sure where to post a 2.0 bug? On 2.00.38 (just upgraded from 1.60. Added device named “Lamp Post” and cannot add to area. Also tried Lamppost with no luck. Changed name to Front Post and works OK.

    Anonymous
    Inactive
    May 13, 2009 at 11:30 pm
    Post count: 1001
    #42674

    I added a LampLinc device with the name Lamp Post and was able to add it to one of my areas.

    Can you expand on what actually happened? Did the device move to the Device In Area window? What is the device type? Was this the first device being added to a new Area? When creating a new Area it is necessary to save the Area before devices can be added.

    I will try to recreate using your information.

    Anonymous
    Inactive
    May 14, 2009 at 8:01 am
    Post count: 8
    #42675

    @grif091 wrote:

    I added a LampLinc device with the name Lamp Post and was able to add it to one of my areas.

    Can you expand on what actually happened? Did the device move to the Device In Area window? What is the device type? Was this the first device being added to a new Area? When creating a new Area it is necessary to save the Area before devices can be added.

    I will try to recreate using your information.

    The device would show up in the devices available list but not copied when double clicked. Not the first device in area. I tried it in two areas as the 7th device in one and the 2nd in another. Double clicking would not move it to devices in area. Running IE on Vista Pro (32 bit)

    Anonymous
    Inactive
    May 14, 2009 at 1:02 pm
    Post count: 1001
    #42676

    Thanks, that is very helpful information. Unfortunately I have not yet been able to recreate. I have Vista Home 32 bit and it recognized the double click on Lamp Post. Do you remember where Lamp Post appeared in the list of available devices, first, last, in the middle? Also what level of IE are you running? I have IE 7 on Vista and IE 8 on XP, both work with Lamp Post as the last device in the list. What is the device type of Lamp Post? Perhaps it has something to do with the specific device type as to why it works here.

    Anonymous
    Inactive
    May 23, 2009 at 5:05 am
    Post count: 17
    #42677

    I’m experiencing random lockups with no apparent reason with the latest beta. There is no INSTEON activity, and suddenly web interface dies. XML interface is still responsive. Web inteface is completely silent, port 80 is open and I can connect to it, but that’s it. The only ways I found to get web interface back is to power-cycle the unit or reset it via xml API. I did a reset and re-flashed firmware again (using dhcp and IE, including uploading DevClusters.xml) and nothing changed – about 15 minutes of work and then it locks up.

    Anonymous
    Inactive
    May 23, 2009 at 6:08 pm
    Post count: 1001
    #42678

    What is the specific image level you are running, 02.00.xx? Can you identify which functional area you were working with before the lockup, Devices, Scenes, Areas, Actions, etc. What were you doing in that functional area? That information will be helpful in trying to recreate the symptom.

    Anonymous
    Inactive
    May 23, 2009 at 7:30 pm
    Post count: 17
    #42679

    Version 02.00.38, d/l and installed yesterday. I was adding devices, copy-pasting insteon addresses from my 1.60 xmls. Most of my devices have no more than a few links, but adding an existing device took a very long time, minutes. I don’t have numbers, but it feels slower than 1.60. I don’t have any obvious insteon connectivity issues between devices themselves (based on reaction time, number of blinks, etc.), so such long time for reading a device was a bit discouraging. I did get PLM timeout popup once. One time it hung when I clicked on “actions and holidays”, second time I don’t remember doing anything special, just adding devices, removing old links, and such, basically reading and writing devices. Hopefully it helps with debugging.

    Anonymous
    Inactive
    May 23, 2009 at 8:07 pm
    Post count: 1001
    #42680

    Thanks, I’ll see if I can recreate using Devices. Some of the V1 images wrote a large number of empty link records when writing Device link records. It had no impact on device performance because of the speed of the processor in each device but when reading a link database when a device is added to EZSrve could take several minutes while EZSrve reads those empty link records 1 byte at a time until an EOL entry is found. SHN recommended resetting the devices before moving to V2 but of course that means recreating the Scenes from scratch. After you get the devices added and the V2 xml updated with the active link information you can hardware reset the device and use SYNCH DEVICE to rewrite the active link records back to the device under V2. That will eliminate any empty link records should it be necessary to add the device again.

    Thanks again for the diagnostic information. I’ll let you know what I find.

    Anonymous
    Inactive
    May 25, 2009 at 2:52 am
    Post count: 17
    #42681

    Thanks, grif091, re-provisioning the devices from EZServe did improve the speed of adding-removing links noticeably, it is a useful tip, I will have to do it for all devices eventually, even though it did not help the web interface issue. It stopped working again, I did not do anything, just left 3 IE windows with EZServe inteface open overnight. Reset to port 8002 helped as usual.
    I do have another issue to report – I was creating a simple scene, 1 controller (IconOnOff), 1 responder (IconOnOff) and controller link was created with 00-00-00 attributes. It did not work until I recreated links by exporting, editing to have FE-1F-00, re-importing xml and updating the controller device. Now my scene works in reality until I modify it in EZServe, after which I get 00-00-00 again, it is repeatable. Both ICONs can be conrolled from EZServe w/o problems, so it is most likely not a connectivity issue.

    Anonymous
    Inactive
    May 25, 2009 at 5:18 am
    Post count: 1001
    #42682

    I’m sorry but I am having a problem following the link failure. You have an ICON Relay A as the controller and ICON Relay B as the responder. The “Controller of” link record in ICON Relay A has an LDx string of 00,00,00. You did not mention, or I misunderstood, what the LDx values in the “Responder to” link record in ICON Relay B. Normally this would be specified as something like FF,1F,00 in ICON Relay B as the responder which indicates full bright (0xFF), fastest ramp rate (0x1f), output unit 0 (0x00). Without knowing what was actually in responder ICON Relay B link record I don’t know if ICON Relay A would be able to turn On ICON Relay B. It is the LDx data in the “Responder to” link record in ICON Relay B that is used when ICON Relay A as the controller directs ICON Relay B to turn On. If the LDx string for ICON Relay B was specified as 00,00,00 then controller ICON Relay A could not turn On responder ICON Relay B because the bright level of 0x00 would have the effect of turning an On command received at ICON Relay B into an Off operation.

    An LDx string of 00,00,00 in the controller ICON Relay A “controller of” link record should be fine as the hardware does not use the LDx string from the controller device, ICON Relay A. When a link is established with the hardware Set button technique the LDx string in the controller device (ICON Relay A in the case) often has the Device Category, Subcategory of the responder device but it is not used by the controller device. Only the LDx string in the responder device (ICON Relay B in this case) has an operational effect.

    Can you repeat what LDx values you specified for the responder device when the Scene was defined to EZSrve and what was actually written in the link records, if you know.

    As far as controlling the ICON switches from EZSrve, “Direct” commands are used which do not use anything in the link database of either device. Only when ICON Relay A paddle is pressed to control ICON Relay B are “Group” commands used which do use the LDx values in the responder device link record in ICON Relay B.

    I have not yet been able to recreate a hangup defining Devices but I have not left multiple IE sessions running over night. What are you doing from multiple IE sessions logged into EZSrve?

    Anonymous
    Inactive
    May 31, 2009 at 5:01 am
    Post count: 17
    #42683

    grif091, thanks for your help. I have everything working much more reliably now, but I am not sure what exactly fixed it. I added 3 filters to my fridge, router/cable modem/server/switch/nas/printer stack (which is electrically near the EZServe) and TV, added a “dryer” phase bridge in addition to existing RF ones, resync’ed all devices as you suggested and upgraded EZServe to latest beta, 02.00.43.
    Interface in IE is reliably stable, provisioning of links is faster and also more reliable and scenes are created with valid links now. I will continue testing but I got a feeling that the issue might be caused by some powerline noise I did not have when I was playing with 1.60. Thanks for your support anyway!

    Update: I somehow managed to hang the interface again with the new setup. And again – nothing obvious, unfortunately, I was testing new action interface and was adding actions/conditions and testing them on a few switches. I had one IE tab where I edited actions and a second IE tab with details of some device with no activity from me, just the usual auto-refresh. I also had a TCP session open to port 8002, using netcat (read-only, I was looking at “ClusterResponse”s in traffic). At some point interface just became unresponsive, “Reset” on TCP interface worked though.

    Anonymous
    Inactive
    June 17, 2009 at 1:36 am
    Post count: 9
    #42684

    DOwnloaded the beta and updated using the java applet. Unit unresponsive. Tried to load 2.0 with the TFTP server which did not work. was able to reload 1.60 using tftp server. Uploaded saved XML files and I’m back up. I’m really interested in trying out 2.0. What did I do wrong?
    A couple of 2.0 questions:
    Is it possable to edit 1.60 xml files to avoid re entering everything?
    Do I really need to reset all devices? I have a couple of inline devices that are hard to get to.

    Thanks

    Anonymous
    Inactive
    June 19, 2009 at 3:00 am
    Post count: 1001
    #42685

    There is a DevClusters xml file that is part of the download and is required to run V2. It is not automatically loaded by the Java application.

    There is a significant difference in the xml file layouts between V1 and v2. Trying to construct a V2 file based on a V1 starting point would be practically impossible.

    You can add a device without resetting it but two things to consider. V1 in some cases wrote dummy placeholder link records which could make adding a non-reset device a long process as the place holder link records are retrieved looking for an End Of List record. This can be resolved by doing a SYNCH DEVICE from V2 after the device has been added to V2. Secondly, the scene definitions in the xml that the link records may represent will not be automatically redefined in the V2 xml. If there were no EZSrve scenes in the devices then nothing would be lost.

    Anonymous
    Inactive
    June 19, 2009 at 9:57 am
    Post count: 9
    #42686

    I downloaded the 6/18 release and tried again, I have most things working. Need yo do a little cleanup becuase I did not reset everything.

    Actions are Great!

    One question:

    I would like to have a condition based on receiving an on from my EZsnsRF something if ezsnsrf group 1 goes on and time between sunset& sunraise then

    How can this be done and if it cant please add support for something like this.

    Thanks

  • Author
    Posts
Viewing 15 posts - 16 through 30 (of 35 total)
Previous 1 2 3 Next
  • You must be logged in to reply to this topic.