AnonymousInactiveFebruary 22, 2008 at 3:33 amPost count: 6
Does anyone else think the simplehome products are somewhat lacking in documentation?AnonymousInactiveFebruary 22, 2008 at 3:32 pmPost count: 408
Maybe – can you give me an example of what you are referring too? There is a balance – and I recognize we at Simplehomenet could do better on providing examples. We are working on improving that side of the material.AnonymousInactiveJune 13, 2008 at 2:25 pmPost count: 11
I would like to see examples of macros, and it would be helpful to hear about how people are using EZServe to automate their homes. The latter would be great marketing for EZServe that would increase business and increase customer loyalty.
How about we start a Wiki?AnonymousInactiveJune 13, 2008 at 4:34 pmPost count: 408
I love the idea of a wiki. Let me look into getting something setup.AnonymousInactiveJune 14, 2008 at 8:09 pmPost count: 14
Here’s an example where documentation needs to be improved:
With firmware 1.51 scenes can be controlled from the Device View/Control page. When I first tried adding a scene to an area, my scene was not in the list of available devices to be added. After a bit of playing around, I found the trick: the EZSrve must be included as a controller for the scene if you want to include it in an area.
This makes perfect sense when you think like an Insteon device, but less so if you are a casual user.
The next logical question is what unit # to use when adding the EZSrve as a controller. The doc sort of implies that 1 is in use and subsequent numbers should be used for scenes. If that’s the case, then do I need to manage EZSrve unit numbers myself and be sure not to create a conflict?
Finally, do I need to add the EZSrve as a responder? The screen shot in the doc does, but there’s no explanation of whether this is required or not.
Having these sorts of questions documented makes the difference between the EZSrve being a joy to use vs. a source of frustration.
PS: if someone can help answer these questions I would be grateful.
Alex.AnonymousInactiveJune 14, 2008 at 9:48 pmPost count: 1001
As you say, the documentation is lite. I like the way you said you have to think like an Insteon Device. Of course that requires you have the underlying Insteon knowledge. Only a Controller can control a Group so for the EZSrve to control a Group/Scene it must be defined as a Controller of the Group/Scene. Makes sense when you think like an Inston device.
I think you do need to assign a unique Unit (Group) number to each scene for two reasons. First, thinking like an Insteon device, when a Group Broadcast message is issued, it only has the controller device address and the group number, so for responders to begin to react to a Group Broadcast message (for performance reasons only) it must match the controller device address and group number when it looks through the link database. Of course the following Group Cleanup Direct message does have both the From and To Insteon addresses but the group number provides the number that must match the responder link record containing the device characteristics (bright, ramp rate) for the group. As a Keypadlinc can have the same responder in different Groups (buttons) where the Group (button) number identifies the specific group, EZSrve must use unique Group/Scene numbers for it to work correctly as a multi-unit controller, just like a Keypadlinc does for its multiple buttons. Except in this case, EZSrve is not limited to 8 buttons (groups).
Second, I have seen that macros store only the Group number (not the scene/group name) when a Scene/Group is the object of the Then clause of a macro. That suggests the developer was assuming each scene for which EZSrve would be a controller would have a unique Unit (group) number.
EDIT: Timers also store the Group number of the scene rather than the scene name itself. Just more confirmation that the Group (Unit) number must be managed correctly. I just tried a Timer controlling a scene which worked and the timer entry in the XML has the Unit (Group) number. Caution here because I created two scenes with the same Unit (Group) number (on purpose to see if EZSrve would allow it) with different names of course. The timer that turns on the first scene also turns on the second scene because both scenes have the same Scene/Group number. At some point EZSrve should insure that scenes with EZSrve as the controller do not get assigned the same Scene/Group number.
As for adding EZSrve as a responder, thinking like an Insteon device, it is not technically necessary for a controller of a group to also have a responder link but if you want the controller to stay in sync with the status of the responders in the group then the controller also needs a responder link. Of course if the responder(s) in the group are responder only devices (like a Lamplinc which cannot function as a controller even when local control, load sensing, turns on the load) then you would not want a responder link for EZSrve. On the other hand, if the responder(s) in the group are Switchlincs, where you can also control the load with the paddle, then you would want EZSrve to also be a responder so it would know that the load was turned on/off by the paddle.
Reminds me of the movie “Contact” where some guy says “if you think like a Vagin, in multiple dimensions”; until EZSrve documents all aspects of the Insteon architecture as it applies to EZSrve, it really does help to think like an Insteon device. I do like your analogy.
- You must be logged in to reply to this topic.