HOME Forums Gateways EZSrve Issues with EZServe reliability after 2.01 upgrade

Viewing 15 posts - 16 through 30 (of 31 total)
  • Author
    Posts
  • Anonymous
    Inactive
    Post count: 27

    Stuart,

    Thank for the reply. I am sending the xml files to Lee and perhaps some good stuff will come to light as we seem to have identical issues here. What plm version to you have? Just curious.

    Gene

    Anonymous
    Inactive
    Post count: 1001

    I received your files. The symptom is related to the Devices.xml file as that is the only file I uploaded to my EZSrve and I see the same slow processing. I’ll post an update as soon as I discover what is unique. Thanks for the files.

    Anonymous
    Inactive
    Post count: 55

    @Gfridland wrote:

    What plm version to you have?
    Gene

    GetVersion reports 0x63.

    Anonymous
    Inactive
    Post count: 27

    Stuart, Thats the same one that I have. Lets see what we find out from Lee!

    Anonymous
    Inactive
    Post count: 27

    Grif,

    You are quick!!! Thanks for the update. I am very interested in your findings.

    Thanks for your efforts.

    Anonymous
    Inactive
    Post count: 27

    Here’s an update on my 2.01 issues:

    Aparently, the flash interface corrupted the actions that were set up and is likely the cause of the inoperability of my timers/macros. After re-creating all the actions from scratch, they began to function correctly. An important point here was the need to actually delete the action entirely from EZServe prior to recreating the same action to replace the corrupted one. This appeares to have resolved the functionality issue related to the actions/timers/macros.

    Other issues are still open pending feedback from Simplehomenet. These include slow load time after reboot and X10 funtionality.

    Looks like SImplehomenet/ Grif have some ideas on the slow reboot/initialization problem. Thanks!!!

    Anonymous
    Inactive
    Post count: 27

    Well, it’s official…EZServe is non responsive and non rebootable.

    I tried to log in after timers refused to fire and couldn’t. The discovery tool sees the IP, but does not see FW version. No ability to log into EZServe with password. Tried to reset to factory settings…nothing!!!

    Tried to downgrade to 1.60…unable.

    Looks like the end has come!!!

    Good luck to all that are still running…I hope that there is a fix soon.

    Anonymous
    Inactive
    Post count: 1001

    Have you tried using SolarWinds TFTP server to load either the 1.60 or 02.01 image. Simplehome documented the TFTP recovery steps in a topic toward the top of the EZSrve category. Is the IP address that the Discovery tool sees .125?

    http://simplehomenet.com/forum/viewtopic.php?f=15&t=632

    Anonymous
    Inactive
    Post count: 55

    @Gfridland wrote:

    I tried to log in after timers refused to fire and couldn’t. The discovery tool sees the IP, but does not see FW version. No ability to log into EZServe with password. Tried to reset to factory settings…nothing!!!

    Gene,

    Do you mean that the discovery tool sees the EZSrve and tries to open the web interface but the default login and password don’t work? If so, I’ve seen that one at least twice during my EZSrve 2.01 adventures over the past week. I was able to recover from that. If I remember correctly I had to use both the TFTP solution Lee refers to (make sure you turn off Windows firewall) to reimage the firmware to 1.60 AND a hard reset after that. I ran into a slightly different situation (see this post) that required both steps… I’ve drawn some conclusions that are just guesses at this point:
    1) the TFTP process only replaces the EZSrve firmware but doesn’t restore the flash memory the EZSrve uses for the xml files to factory defaults. Just a guess, but I bet the username/password are stored somewhere in flash.
    2) for some reason even though it appears to work, the reset process done through the Discovery tool or the web interface doesn’t always reset the flash to factory defaults (I’ve usually seen this after I’ve trashed an xml file)
    3) the hard reset (paperclip in reset hole) will reliably reset the flash memory (but won’t recover corrupted firmware)
    4) some of the scenarios I’ve run across with 2.01 corrupt both the firmware and the flash memory
    5) I don’t think the PLM links are recreated automatically after a factory reset, so I have found that getting scenes to work after a hard reset requires doing a “sync device” on the EZSrve PLM

    Good Luck

    Anonymous
    Inactive
    Post count: 27

    Thanks for the reply and ideas…

    Lee, after such a frustrating evening last night, I gave up trying anything beyond the basics.

    The IP that was displayed was the correct IP (most of the time). On occasion, there appeared to be an unreccognizable IP (267…???) don’t remember now, but all values were different than normal.

    This morning I TFTP’d 1.60 image to the ezserve and uploaded my old (1.60 version) .xml files. Wow…works great. Timers, interface, macros, X10 all work flawlessly as prior to 2.01 experimentation. The image loads fast, devices are present immediately. Looks like i’m beck to a stable operation.

    SCSweet,

    I believe that you and I had the same set of issues/experiences with our 2.01 upgrade. The discovery tool was able to see the EZServe (although not consistantly). Normally, when the EZServe is running OK, the discovery tool displays the FW version. When the problems began, only the MAC and the IP adress were displayed. I was able to click on the IP to open the browser at which point the browser either timed out waiting for EZServe to prompt a log in, or sporadically asked for a password, but did not respond to ANY password attempt (both my own or the default one). I tried the paperclip trick, tried to power cycle, tried to reset through the discovery tool…no success. I then tried to reload FW through the discovery upgrade, it took the default password and looked like it ran through the process correctly, messaged that the upgrade was done successfully, but no change in functionality was noted. Not able to log in, no FW displayed in the Discovery process, and sporadic password prompt through Discovery tool or direct IP input into browser.

    At this point, I decided to try to Downgrade to 1.60 through the dicovery tool, after upload, result: upgrade FAILED. Tried to log in, nothing. Retry…1.60 upgrade success, but no log in ability after reset, power cycle, paperclip reset.

    Looks like TFTP was the only way to get back to functionality with 1.60, I’m a bit gunshy to attempt to reload 2.01 until there is a fix to these issues.

    Anonymous
    Inactive
    Post count: 1001

    Glad TFTP was able to get you back to 1.60. You should be able to upgrade from there when a new image is released. Sure would like to know what it is about your configuration that is exposing a hole in the code somewhere. I have nearly as many devices, more actions and I do a very large amount of Action definition and change during testing and don’t see in days what you encounter in hours. I’m sure they will get to the bottom of it. V2 has so much more to operate with; once this initial hump is cleared things should be better for all. Thanks for all the information you have passed back.

    Anonymous
    Inactive
    Post count: 27

    Lee, What PLM version do you have? Could this difference be at all related to the hardware?

    Anonymous
    Inactive
    Post count: 1001

    My PLM is revision 76. I think Smartlabs is up to revision 8 something. I don’t think the slow restart is related to PLM level as your devices file, although a few more devices (and many more links) is slow on my EZSrve where my devices and actions file are not. Also there is no powerline traffic as the EZSrve initializes itself during a restart. If it was something related to Insteon traffic or X10 traffic, traffic timing, that sort of thing could be influenced by the PLM level for sure but I don’t see a connection to startup speed. I’ve got a few clear hours later today. I’m going back to using your devices file and see if I can find something specific that influences this.

    Anonymous
    Inactive
    Post count: 55

    I’ve been told by SHN that they have identified a problem with the filesystem that explains the problem we are seeing and are working on a firmware upgrade that will hopefully be available next week.

    Anonymous
    Inactive
    Post count: 1001

    The problem triggering multiple Actions from the same X10 signal is working on image 02.03 now available through the 1.1 Java Discovery tool as well as the Downloads section of the web site.

    Also I am now able to trigger a Scene with an Effect on 02.03. One post indicated that only certain Scenes would not trigger. I could not get any of my EZSrve as controller Scenes to trigger so 02.03 has improved things if not completely resolved the problem.

Viewing 15 posts - 16 through 30 (of 31 total)
  • You must be logged in to reply to this topic.