-
AuthorPosts
-
AnonymousInactiveJanuary 20, 2009 at 1:42 amPost count: 29
Hang on, I looked under the Control Tab and see this is the data it receives:
SndIns
0X2
0X62
0X1
0X7E
0XA8
0XF
0X19
0X00
0X6AnonymousInactiveJanuary 20, 2009 at 2:44 amPost count: 1001Sorry, I should have been more specific. The Insteon Traffic screen would not show what I was interested in. After connecting the SHN Utility to EZSrve, click on the EZSrve/EZBridge tab, then the Control tab. That screen has a Data Received section which displays XML. It is the Data Received window, or the XML log.txt file that will contain the XML Status Request command in question. After selecting the Control tab, go to Scene Management in EZSrve and Add EZServe as a Controller to a new Scene. The XML traffic in the Data Received window has the most recent XML traffic at the top of the Data Received window. If you click on Enable Logging in the lower right corner of the Control tab screen, then Add EZServe as the Controller of a new Scene, the XML commands are written to a log.txt file located in the subdirectory where the SHN Utility is installed. In the log.txt file the latest XML commands are at the end of the file.
I am all but positive we know what the problem is. The Status Request command should not be issued to check the status of the EZSrve itself. Even more so now that multiple users are seeing the same thing. The problem is I have an EZSrve that is nearly a year old so I do not see the Status Request command fail even though I expect that it is failing on new EZSrve devices with the most current internal PLM. SHN is working on the 1.60 image and it would be very helpful if someone can confirm that the Status Request command (cmd1 value 0x19) is actually being issued by looking and/or posting the command and response that occurs when EZSERVE is Added (attempted). That way we can be sure this will be solved when 1.60 is released in the next few weeks.
AnonymousInactiveJanuary 20, 2009 at 2:48 amPost count: 1001Your last post was not there as I typed my last post. Thanks, that is exactly what was needed. That 0x19 command (parameter 7) should not be there and will be fixed in the 1.60 image that will be available in a few weeks. Really appreciate you taking the time to run the trace.
AnonymousInactiveJanuary 20, 2009 at 3:01 amPost count: 3And I have just tried the same thing – no traffic either.
AnonymousInactiveJanuary 20, 2009 at 3:08 amPost count: 3Sorry I submitted my last comment out of sequence without reading page 2 – but I’ll stand aside and wait for 1.60.
AnonymousInactiveJanuary 20, 2009 at 3:24 pmPost count: 29Excellent! I’ll stay put and look for the next image. Thanks for taking me around the tools, I’m sure that will come in handy as I pick up on skill with this. Your posts helped me find output that looked like yours, and look under each of the tabs. I really appreciate the support from this community (and the respect to questions from newbies). I think that also has a halo effect over the SHN products in general.
AnonymousInactiveFebruary 1, 2009 at 4:37 pmPost count: 29I upgraded from Firmware 1.59 to 1.60 (I found the code on the master list of available firmware, and not under downloads for the EZServe itself). The Scenes work perfectly now. I realized after some testing that each scene needed to be on a unique Unit address to work correctly (makes sense). Next step is to enter Hex values so I can get a dim setting other than a multiple of 20%. Thanks for the excellent support.
-
AuthorPosts
- You must be logged in to reply to this topic.