Issues with EZServe reliability after 2.01 upgrade

[Anonymous]

#40185

I am wondering if it’s just me or others have seen similar problems after upgrading from 1.60 to 2.01. My upgrade process went well and I was able to use the java utility to perform the firmware upgrade. I had no problems logging into and seeing the 2.01 screen through the browser. I was able to add all devices with only little difficulty (the addition process would stall and I would have to reboot the EZServe after which everything resumed in fuction). This is when the issues began:

Some facts regarding my setup: 30 insteon devices, 1 X10 device, all are hard wired, in-wall devices. 6 Timers, 2 macros, 3 defined areas.

Issues experienced are as follow:

1) EZServe appeared reboot without prompting during the configuration process. This happened a number of times while I was either setting up my geographic loaction, setting a password, creating and action and area. Upon reboot, the unit would take a REAL long time to again display all devices, areas, and actions. I was actually able to log into the EZServe (with the default password) while the unit was initializing and importing the devices/actions/areas. I was able to see the process as more and mored devices appeared in the device list. I have never seen this phenomenon with 1.60 and I am not sure if this is typical after each reboot. The process would take +/- 30 minutes and all my personal settings would once again be loaded in the EZServe. My password would revert to my own after that time.

2) Timers would not function properly sporadically. The actions were set up and tested. All fired correctly the first night, but stopped working on the second evening. I rebooted the EZServe, function returned for a breif time after which some actions worked while others did not. Never had this problem with 1.60 or previous sorftware.

3) I decided to try the Flash interface to see if it would work faster/ more reliably. After logging in, using the default password successfully the first time but not the subsequent times( seems to have defaulted back to my user set password), I was able to see the flash inteface (although without the device graphics). I attempted to modify an action at which time the entire inteface froze. I could not see the device on the discovery tool, and the clock kept running on the flash screen for a REAL LONG TIME. At this point, the EZServe was frozen and not communicating with the network (no green light flashing on the unit). After rebooting, and again waiting for all devises to upload within the EZServe, I noticed that the actions that I was trying to modify were missing from the EZServe and the Unit was not triggering the timers again. I rebooted the EZServe (again) and some timers began to funtion properly.

Please advise if you have any thoughts on what I can try next to revert to a reliable operation of the EZServe…do I go back to the 1.60? Or is there hope here?

[Anonymous]

#42961

One more issue experienced after the upgrade: X10 monitoring in order to trigger an action does not seem to work with the 2.01. Worked well with the 1.60. I read some other posts where the same problem was encountered, but did not se a resolution. Any help here would be great as well. (looking at an X10 photosensor to trigger an action which would turn on a group of insteon controlled lights)

Thanks again,

[Anonymous]

#42962

@Gfridland wrote:

One more issue experienced after the upgrade: X10 monitoring in order to trigger an action does not seem to work with the 2.01. Worked well with the 1.60. I read some other posts where the same problem was encountered, but did not se a resolution. Any help here would be great as well. (looking at an X10 photosensor to trigger an action which would turn on a group of insteon controlled lights)

Thanks again,

I have a similar setup with about 20 Insteon devices, more X10 sensors and a bit more complicated Macros / Actions (I’m using X10 IR543 receivers and a harmony remotes to control scenes in my Home Theater and Great Room). When I was on 2.01, I had a very long load time (approximately 30 minutes). I have gone back to 1.60 pending feedback from SimpleHomeNet.

With regard to the X10, IIRC there are two choices in the condition window for the attribute for an X10 device (status or X10 control). I found that I needed to choose status, and enter 3 for “off” and 2 for “on” in the attribute value to make it work correctly. I was able to get X10 triggering to work with 2.01 using that approach. I believe that the 2.0 Operation Thread shows this in detail.

I also found that using the SimpleHomeNet utility was very helpful for troubleshooting X10 triggering. I don’t have it in front of me at work, but there is a way in the the control tab to see X10 messages come across the interface.

Good luck.

[Anonymous]

#42963

Thanks for the reply SCSweet…i didn’t thin that the SH utility works with the 2.01?

I have been using the EZServe for a long time and have seen issues with freeze-ups here and there, but this new 2.01 seems to really limit reliability and speed. Perhaps 1.60 is the way to go until these issues are resolved.

I will try the Status vs X10 tonight to see if it will help with the X10 trigger function. It just seems strange that it was so easy with the prior F-Ware.

The other surprise for me was the FF, 00, 2, 3, etc. in the configuration process really complicates the setup. It is significantly less user-friendly…at least for me.

[Anonymous]

#42964

The X10 Actions work on 2.00 and 2.01. Stuart in his previous post described how to define a Condition that triggers from an X10 On or Off. I had tested X10 triggering on 2.00 and just ran a test on 2.01 and can confirm X10 triggers are working. There is one known issue where multiple Actions being triggered from the same X10 event will fire only one Action.

As for the long response times for various screens, that is normally the result of one of the EZSrve threads running in a loop slowing the entire process down. A 30 minute start up is not normal. I have some concern that one of the xml files has gotten corrupted with all the reboots that have gone on. What browser are you using and what level? Did you Reset the devices before adding them to 2.01? If you did not reset the devices it can take a long time to add a given device. Restarting EZSrve in the middle of that process could have damaged the devices xml file.

[Anonymous]

#42965

Sorry, I should have mentioned that I was using an updated version of the SHN utility that Lee Griffith (grif091) provided. See this thread

[Anonymous]

#42966

Grif091,

I tried to upgrade both ways…without resetting all devices. When it was slow to respond, reset all the devices to factory default and re programmed/re-linked all devices to the EZServe, after that process (a long and frustrating one) the unit acted similarly.

I used the discovery tool to upload the firmware, amd tried both the IE8 and google chrome browser. Same results have been seen with all combinations.

The X10 DOES NOT FIRE in my setup. I will try SCSweet’s reccommedation on the configuration, but to answer your question, i have two effects and neither are triggered by the X10 so I am not sure if it is really getting the trigger or if it is not reacting to it. I have not had any X10 problems prior to upgrade.

[Anonymous]

#42967

Did you do the entire EZSrve Reset process again before adding the reset devices? If not, just adding reset devices again would not fix a corrupted xml file. Some of the 1.x images wrote place holder link records during some of the processing. Adding a device with these place holder records can take a very long time because all these place holders have to be read one byte at a time to find the true End Of File link record. I suspect that what you thought was a hang up was EZSrve reading these place holder records. It is only a theory but it does take a very long time to read through those place holders. I have a PLC and run SDM3 with the window open so I can watch the actual Insteon traffic as it flows. Does not speed up the process but I know that EZSrve is still working. Doing a restart during that process could have corrupted the devices xml file. The only way I know to fix it is to Reset EZSrve to erase the xml files and start over.

I would expect the X10 trigger Action to work once the EZSrve is functioning without all these delays in processing. There is a screen capture of an Action and Condition definition using X10 B16 On (2) as a trigger to turn on an Insteon switch that is a working example on my EZSrve. Look toward the middle of page 1 of the following topic for the screen captures. They show both the X10 Condition and the Action Effect.

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

EDIT: I would run IE8 in Compatibility View mode when running the EZSrve HTML interface.

[Anonymous]

#42968

Grif,

Thanks for the explanation. I will try to repeat once again after doing a complet reset. The hang-up issue that I ma referring to is not the device addition process, but the process after a reboot. When the EZServe reboots, once I log in, no devices, actions, or areas exist until the EZServe processes the data. You can actually see more and more devices appear in the pull down device menu as time goes by. It takes approx 30 minutes for the EZServe to FULLY initialize with all my personal settings.

How quickly should the EZServe fully boot up (after a reboot) with all my devices and actions loaded? Should it be more than a few minutes or does it take considerable time for the XML files to be imported? What do you think is causing this delay if it is not normal?

[Anonymous]

#42969

When I do a Restart I wait a minute or two before logging in. From login enter to initial Device View/Control screen is a matter of seconds which is displaying an Area with three devices in the Area. At present I have 8 devices defined, 10 Actions, and a few Scenes. My configuration very much depends on what I am testing at the time. The house has more than 50 Insteon devices so I can create most any environment within the limits of the devices I have installed. The only thing that may takes minutes to happen is when a device is involved. Adding/deleting a device, creating a Scene, adding/deleting links, that type of thing where Insteon messages are involved and the link database of one or more devices are being accessed with 1 byte at a time read/write access. Those types of things can be very slow. I have one configuration that has more than 100 links in a device. Takes a long time to go through that link database. Because the PLC SDM3 window is showing most of the Insteon traffic, I have a positive indication that EZSrve is not just sitting there spinning its wheels.

If you want you can send me your devices.xml file and actions.xml file which I will load on my system and see what results I get with your files. If they are damaged I would expect to see something similar to what you are seeing on my system. If the file system itself on your system has a problem I would not see that here. A Reset should resolve that. You can email the files to lwgwork@embarqmail.com it you want to try that route.

[Anonymous]

#42970

Thanks for the offer…I will try a few things tonight to see if i can resolve anything, if i have no success, I will send you copies of my files for your review.

[Anonymous]

#42971

Let me toss in my experience to see if it helps any…

I have similar slow reboot symptoms. My current 2.01 setup has about 20 Insteon devices, ~20 X10 devices (mostly motion sensors and virtual devices that I’m using as triggers), ~15 scenes and 20 actions. If I log in a few minutes after reboot I see no areas defined. If I navigate to the devices page, I start seeing the list of devices. Refreshing the page shows devices being added slowly to the device dropdown. There are no actions, and no scenes (pulling up the scene page before the devices are fully loaded gives an error message about not being able to communicate with the PLM). Once the device list is fully populated (takes 10-15 minutes), then the scenes get loaded, then the areas get populated. Actions get populated last. The total process took about 30 minutes. I found that if I try to access an area before the load completes, the EZSrve hangs and if I remember correctly required reset and reload of the xml files.

I initially thought that my problems were related to an out of sync devclusters file. So I started from scratch after 2.01 and Discovery 1.1. became available. Initially, with a few devices and no scenes areas or actions, the EZServe rebooted pretty quickly. I tried to save xml files at intermediate steps during the process. Once I got everything loaded, there was a dramatic slowdown. I went back through and synced each device with the EZServe and used the SHN utility to verify that the links in each device matched what is in the EZSrve (some of the devices had accumulated a lot of duplicate links). That didn’t seem to make a difference in the speed of the reset process. I’ve been working with SimpleHomeNet and sent them my xml files over the weekend thinking that I might have a defective device (I’ve also had intermittent problems with X10 macros not firing with the 1.60 FW ). I’ll post again if I learn anything.

[Anonymous]

#42972

SCSweet,

Wow…the SAME EXACT issue that I have on the Reboot. Slow reboot with Devices loaded first (15-20minutes), nothing in the actions, or areas untill that step completes, thent the actions, followed by areas. Total time to loadt approx 25-30 minutes. As I have only a few actions, the longest process is the device addition.

The other weird symptom is when I log in after a reboot, it appears as if the EZServe is at a factory default configuration. The password is the default, the location settings are not mine but the default, the time zone is default, etc…at some point, the EZServe asks me for the password again at which point it reverts to my personal, saved password.

When you went back to the 1.60, did you experience the same problems or did the boot-up revert to normal? I’m thinking of this as a fix until there is more clear understanding of this problem as I expect that we are not the only ones. I have gone through the process a few times now with similar results, so another evening programming may not be the most productive thing if the results do not change.

I look forward to your feedback on the issues at hand. Perhaps a defective EZServe on my side as well? Not sure what to think at this point.

[Anonymous]

#42973

I added more devices to my configuration, up to 25 devices now, mixture of Insteon and X10. No reduction in response time. I restart, wait about two minutes and login with the Device View/Control screen in a few seconds. Go to devices and see all 25 devices in pulldown list. Don’t think it has to do with the number of devices or I would have expected some drop off with 25.

Gene, perhaps you should send me your files before going through the effort to rebuild. If you are concerned about exposing a static external IP address of the EZSrve, use wordpad to change the devices.xml file EZSrve IP address in the EZSrve information at the beginning of the file.

[Anonymous]

#42974

After going back to 1.60 the reboot/reload issues resolved for me, so I’ve decided to stay at 1.60 for now.

Thanks, Lee for testing your setup with more devices and being willing to test Gene’s xml files. I think that will be very helpful in clarifying the source of our symptoms.

Thanks.

Stuart

[Author]

Posts