-
AuthorPosts
-
Anonymous
InactiveJuly 8, 2009 at 10:24 pmPost count: 1001The request for an all days box was posted just the other day by somebody. Try rebooting the PC and only start the SHN Utility. The 1.81 version will do just fine for this test. Click on Connect and go to the EZSrve/EZBridge Control tab. It should show the version of the current image as that command is the same for V1 and V2 images. Then press the KPL button. The Data Received window displays any xml received without parsing so it will display V2 xml even though 1.81 is V1 only in general. The lower left corner of the SHN display will say Not Connected because the response to the getversion is different in V2 so the left message will not be updated to show the image level connected but the message in the lower right corner should say Connected to EZBridge when the Connect button is pressed. I just ran this test with the base 1.81 version of the Utility so it should produce the stated results.
InactiveJuly 8, 2009 at 10:30 pmPost count: 29Heh, heh. I tried having my monitoring program send a GetClock command when it connects. That seems to have done the trick. I’m now getting ClusterResponse messages when I turn the KPL button on and off. Cool.
This last-client-to-the-party “feature” seems a bit problematic to me. Basically, it means that if you want to do device monitoring, you’re pretty much constrained to having only one client. Either that, or carefully organize things so that the client that is to do the monitoring is always the last one to connect. I wrote my programs assuming that multiple clients could connect at will to perform various tasks, which simply won’t work. The solution for me may be to write my own server, which is the only program to connect to the EZSrve. It would do the monitoring, and also act as an intermediary for other programs that want to connect from time to time to control and check the status of devices.
A better EZSrve design might be to let a client send an xml command to turn device status messages on and off. The messages could be off by default. That way, multiple clients could elect to receive status messages, irrespective of the order of client connections and which clients happen to be connected at any one time.
InactiveJuly 8, 2009 at 11:13 pmPost count: 1001Using my two SHN Utility configuration I am able to issue commands and get the respective responses back to the issuing SHN Utility even when two connections are active. However, the async ClusterResponse comes back to the incidence of the Utility that last issued a command (and got a response). That may be a characteristic of IP rather than EZSrve as it is only talking to a port.
Back in the dark ages when I did some client/server programming for a living the server kept one socket open for new clients to come in on and created a new socket on the server side and passed the new socket number back to the client which would then use the new socket number for all subsequent server communication. That kept each client connection isolated. Did not make any difference at V1 because it looks like IP would return the response to the incidence that last issued the command. Now that V2 has async ClusterResponse xml there may be a use for something more.
InactiveJuly 9, 2009 at 3:16 amPost count: 29If multiple clients are connected, then the TCP/IP socket for each of the connected clients remain open as long as the client keeps it open. So, I suspect the decision about where to send the async ClusterResponse messages is being made by the EZSrve software. My guess is that the EZSrve software is not keeping track of the state of inbound commands received from clients and of the insteon messages received from devices that may or may not be responses to the client commands. So, EZSrve simply figures that it should send any Insteon messages it receives to the client that most-recently issued a command, figuring that the Insteon message is likely a response to the client message. Of course, when multiple clients are connected, that logic can often be wrong. For example, if multiple clients issue commands at nearly the same time, and expect to get a response, then the last client to issue its command will get all of the responses, and the other clients will get none.
To correctly route Insteon messages to multiple clients, EZSrve would have to keep track of the commands it has received from the various clients, and route the responses that correspond to the in-process commands. Of course, this could get very complicated, when taking into consideration all of the errors and timeouts that might occur. Then there’s the question of figuring out whether a ClusterResponse message is an async message or a response to a command sent by some client. And, where should you send the Insteon responses if two clients issue the same command to the same device at the same time?
A simpler design that would also allow for multiple clients would simply be to send all insteon messages to all connected clients. Then, it would be up to each client to figure out which messages are responses to its own commands, or async messages that it wants to handle.
It would be interesting to hear from the engineers at smartlabs about all of this.
InactiveJuly 25, 2009 at 1:41 amPost count: 35I don’t think it matters regarding the LD1/2/3 values when the EZSrve is the responder.
But doesn’t this mean that when lightswitch or some other device notifies EZSrve that you won’t get payload you really want like “light level”?
If I create a reverse link so lightswitch notifies EZSRve on activity…I don’t really want to send another sync message just to get state correct?
Also, a recieved bright event…and you can safely assume light is on.
But getting a series of dim events…you have no idea if light is actually off as there seems to be no ability to insert ‘on level’ into link record from switch to controller.
InactiveJuly 25, 2009 at 1:56 amPost count: 1001The question about LD1/2/3 values was what the values should be when EZSrve is the responder. Since EZSrve itself does not turn ON/OFF when it is a responder receiving a command from a controller, the values in the responder link record have no effect. The values do not reflect the status of the controller sending the message.
Not sure I really understand the question behind your last post.
InactiveJuly 25, 2009 at 2:28 amPost count: 1001Perhaps an example of how hardware normally uses the LD1/2/3 information will clarify things. SwitchLinc A is the controller, SwitchLinc B is the responder. When the link was established between A and B, SwitchLinc B as the responder stores the currently locked in values for bright level and ramp rate in the LD1 and LD2 fields in the responder link record in B.
When A sends an ON command to B, B searches through its link records and when a match is found, B responds by turning on to the bright level, and using the ramp rate that is stored in LD1 and LD2 respectively.
Now replace responder SwitchLinc B with EZSrve as a responder. When EZSrve receives the ON command from A, EZSrve does not “turn on” like a conventional responder so the LD1/LD2 values have no meaning.
When SwitchLinc A sends a command to a responder, the responder has no information regarding the state of SwitchLinc A. If SwitchLinc A had local bright level and ramp rate set it could be half bright and taking many seconds to get there. The responder has no way of knowing any of this information. Even if the responder is intelligent (like EZSrve), querying the controller may not tell the whole story as is the case of a slow ramp rate. A query of the controller will tell you what the current bright level is but if a slow ramp rate is in progress the controller will produce a different bright level on the next query.
InactiveJuly 25, 2009 at 7:26 pmPost count: 35It still sounds to me as if event doesn’t carry event data and I will need separate message sent to get state. By default when you link it is only in one direction (from ezsrve to lightswitch say)…and I need to manually insert a device record in other direction.
When I do this I can’t specify event data in ld1, ld2, etc. Only static values.
So a dimmable lightswitch is capable of sending on, off, dim and brighten events.
Sounds like lightswitch is sending event immediately on press and not waiting until release of switch when actual state/level is known?
InactiveJuly 25, 2009 at 8:59 pmPost count: 1001I used an ICON switch for this test but it applies to other Insteon switches as well. If you press and immediately release the top of the paddle, an Insteon ON command (0x11) is issued. If you press and hold the top paddle the ICON switch sends a Start Manual Change command (0x17) that starts a bright sequence in the responder(s). When the top paddle is released the switch sends a Stop Manual Change command (0x18) which stops the bright level ramp up process in the responder. If you double tap the top paddle a Fast On command (0x12) is issued. SwitchLincs, KPLs, ToggleLincs, they all work the same way.
The Insteon command format for all of these commands is…..
From Insteon device address aa.aa.aa Insteon address of ICON switch
To Insteon device address bb.bb.bb Insteon address of the responder
Flags indicating type of command
Cmd1 field for example a 0x11 is an ON command
Cmd2 field is the Group number of the ICON switch paddleNothing regarding LD1/2/3 data stored in the responders link record flows over the powerline regardless of whether there is a link in one direction or the devices are cross-linked.
You are correct that you have to query the controller (ICON switch in this example) to know what the state of the controller is at the instant the query command is issued. If the result of pressing the ICON paddle is to turn On the ICON switch with a slow ramp rate, when you query the ICON switch you get back a bright level representing the ICON switch bright level at that instant. If you issue the query 5 seconds later you could well receive a different bright level as the device ramps up slowly to its ultimate bright level. If the ICON switch was ramping up at the default ramp rate the query is going to return the “local” bright level that has been configured for the ICON device.
This is the way of Insteon. Nothing here is unique to EZSrve. There is an Insteon Details document on the Smartlabs web site that covers all of this and much more. This document is years old but the basic insteon information, command formats, link record formats, etc. has not changed.
-
AuthorPosts
- You must be logged in to reply to this topic.