Lost insteon status updates

[Anonymous]

#40227

After not dealing with EZServe for a few month and learning more ideas from the net I started working on my automation projects again and realized I lost status updates from my INSTEON devices.
FW2.03 – everything else is working, I can control the devices from EZServe, can read/write links without noticeable delays, plus EZServe sits right on RF bridge and I have filters all over my potential noise-makers, so I am pretty darn sure it is not a communication issue. At least all communication originating from EZServe seems good and I don’t see why it shouldn’t work just as well in reverse direction.
All devices show up as 0% in the web interface, regardless of their actual state. Hitting refresh button doesn’t do any good. Hitting On/Off makes real devices go on or off, but interface still shows 0%.
Upgraded to FW2.06. Same thing.
Harmony interface. Same thing.
Reset (not restarted) EZServe and recreated just 1 device. Same thing.
Any ideas?

P.S. I am very frustrated. For little more than the price of EZServe I could have gotten a PLM and a refurb low-specs netbook and have all my automation completed year ago without endless wait for firmware that works.

[Anonymous]

#43200

Is it a device status change caused by an Action Effect that is not being reflected in the device status display or perhaps a device status change that is caused by one Insteon controller affecting an Insteon responder. If the former can you describe or post the Action that does not get reflected. If the later it is possibly related to a link from that Insteon controller back to the EZSrve that is not in place. A PLM (EZSrve has an internal PLM) is not aware of Insteon switch A turning on Insteon switch B unless Insteon switch A is also linked back to EZSrve. Let me know what specifically is not working and I will generate a test for that condition. Thanks.

EDIT: when you control devices manually from EZSrve that is done with Insteon Direct commands which are not dependent on links. It is very possible to be able to control devices manually using Insteon Direct commands but not have any awareness of device changes by a controller other than EZSrve (switch A controlling switch B) because the necessary links have not been established or have been erased by a Reset and not reestablished.

EDIT2: I just tried controlling an ICON switch and LampLinc through the Device View/Control HTML screen with the On and Off Icons and the device status is reflected correctly although it requires a cycle for the screen to be refreshed before the status change is actually displayed. Also defined two Actions that turned On then Off the ICON switch and the LampLinc and the Device View/Control reflected the device status changes On and Off the next time that screen was refreshed after each Effect. Also turned the ICON switch On with its paddle and hit REFRESH on the Device View/Control screen which resulted in the device being queried with a Direct command and the On status was reflected. What browser are you using? My tests were run with IE8 at the latest level. You might want to reload the 02.06 image to be sure nothing happened during that initial update. Be sure to be in DHCP mode when doing the update.

EDIT3: ran the same Action tests using the Harmony 0.21.7 level and the All Devices display reflected the change in ICON and LampLinc device status when the Actions were triggered based on Absolute= time. The Harmony device status display change is very quick because of the way the Flash interface works. Since nothing seems to be working on your system I’m think an issue with the internal PLM that allows it to send but not receive which seems unlikely since you would see the manual Icon On and Off requests repeated several times (lots of LED blinking) when the On and Off commands were issued. If the PLM cannot receive device query requests it would not be receiving the ACK from the On and Off commands which would cause command retries. That makes a browser issue more likely. What browser are you using and at what level. There is a trace that can be run using the SHN Utility Suite which will show the On/Off commands and the device Query command and response if you have or can install the 1.81 level of the Utility. That level of the Utility does not work with V2 images in the area of device configuration or link management but the EZServe/Control tab that allows xml commands to be executed and responses displayed does work with V2 images. I can post the details on how to accomplish that trace if you are interested.

[Anonymous]

#43201

The change is not reflected whether I manually trigger the switch by pressing the paddle or whether I control it from EZServe UI. No other switches were involved, just two addressable devices – EZServe PLM and IconOnOff. All links in the PLM and the switch were cleared prior to experiments (obviously, there were links later after adding the switch using EZServe UI).
In one of my tests I explicitly added a link with the switch as a controller and PLM as a responder via Action, it made no difference (I know I should be able to get status without such back link while hitting Refresh – a direct command query, as you said). As I said, the linking/adding process was very quick, I don’t think there were any retries. I will time blinking on the PLM when I get home.
The switch and PLM are connected by RF only, can it be something that causes such behavior? I doubt that very much since even direct command from PLM reaches the switch, but that the only non-trivial thing in my setup. If somehow RF could block only one direction of traffic, then I wouldn’t be able to add/look links up from PLM, correct? If PLM receives an ACK to On command, does it do another request to update the status in the UI, or ACK to ON is enough to update status in the UI to ON? If it does not request again, then either i am not getting an ACK (how?) or internal UI logic is broken.

EDIT: please post info on tracing w/o the utility, that should be very helpful. I have no problem with XML and port 8002 if needed, but have not studied the XML API heavily.

[Anonymous]

#43202

A click of the REFRESH button should display current device status returned on the Query command without regard to links. You would not be able to see links retrieved from the device if there was not receive capability. This can be verified by clicking on SYNC EZSERVE while the switch is the current device on the Device Management screen. EZServe will read the device link database and replace the current link information with what is retrieved from the device.

[Anonymous]

#43203

Yes, I think I was reading links w/o problems. I will try to re-do and document my steps today afternoon.

[Anonymous]

#43204

You can use the SHN Utility Suite to trace the actual commands issued and the response received. The following is the trace generated from clicking the On Icon on the Device View/Control screen. It shows the Insteon Direct ON command and response followed by the Insteon Direct Query command and the response. Running this trace will show what is actually happening.

Insteon ON command

Insteon ON command response

Insteon Query command

Insteon Query command response
The 0xFF response indicates the device is ON

Invoke the Utility and “Connect” to the EZServe. Click on EZServe/EZBridge tab and then the Control tab. Enter the following command in the Data to Send window

and click on Send XML button. Then turn On the device using the ON Icon on the Device View/Control screen. You should see a trace similar to the above. After running the trace change the command in the Data to Send window to Off and click on Send XML to turn the PLM Raw trace Off.

[Anonymous]

#43205

Thanks a lot for the trace command, it helped. I telnetted to port 8002, got the trace and after trying to decode commands for several minutes realized that something was very wrong, I saw messages with addresses I don’t have, I saw messages of 3 bytes and I guessed it would not be a bad idea to do a major clean-up in EZServe. I did another reset, uploaded empty xmls and then DeviceCluster.xml, did “Sync EZServe” on PLM itself, removed few records which looked like junk and after adding the devices everything works now. I have no idea how and which file got corrupted but that is the most probable cause. Can such corruption be caused by a power spike? Putting EZServe on a power filter or a UPS would be kind of counter-intuitive.

[Anonymous]

#43206

That falls into the category of anything is possible but a power spike probably did not cause the problem. The memory in EZSrve where the xml files are stored is non-volatile so corruption should be a very rare event. Always good to have a backup of the xml files anyway. There were some problems with file management on earlier images. That is a more likely cause than a power problem. You cannot put EZSrve on a FilterLinc or a UPS as either will block Insteon signals.

[Anonymous]

#43207

UPS may or may not be possible due to zero crossing synchronization but simple power surge filter is definitely possible with Access Point before EZServe – just tested it.

[Anonymous]

#43208

Some UPS units that use steeped sine wave outputs. Can damage some modules using transformer less power supplies.
I have personally burned out a module while testing with an UPS.

[Author]

Posts