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.