LeeG Posted March 11, 2014 Share Posted March 11, 2014 The Query Input response is 0x30. It is a bit map just like the Query Relay response. Inputs 5&6 On (wired On), all other Inputs Off. When that value is falsely evaluated as Relay Status, Relays 5&6 are marked On, all other Relays Off. The Relays were marked accordingly to the Input response 0x30. Relays 2&4 were On (and are still On) and are now incorrectly marked Off. Relays 5&6 are marked On because Input 5&6 are wired On. The Query Relay taken just before the Query Input shows the correct Relay Status, Relays 2&4 On, all others Off. Why this happens is unknown by me. Why there is a 4 second delay in either the EZIO8SA sending or the PLM passing the Relay response message on to the ISY is unknown. Perhaps the EZIO8SA was handling changes to the Inputs, perhaps the ISY was busy doing something that prevented it from reading the PLM serial port for 4 seconds. Since the delay happened twice back to back it was something that happened over several seconds to affect two Relay Query responses. Link to comment
johnnyt Posted March 12, 2014 Author Share Posted March 12, 2014 Why this happens is unknown by me. Why there is a 4 second delay in either the EZIO8SA sending or the PLM passing the Relay response message on to the ISY is unknown. Perhaps the EZIO8SA was handling changes to the Inputs, perhaps the ISY was busy doing something that prevented it from reading the PLM serial port for 4 seconds. Since the delay happened twice back to back it was something that happened over several seconds to affect two Relay Query responses.I don't have anything connected to the inputs other than 5&6 to gnd and I don't have the kind of busy ISY situation I used to see when I had to query 10 IO Lincs, pre-EZIO8SA. Incidentally, in case anyone is thinking "just stop querying and your problems will go away", the reason I do the querying is because whenever I've not done it in the past, I would sometimes find things that weren't working as they should. The 3AM "query all" would also end up reporting something wrong just about everyday. While one might be tempted to say that at 3AM the insteon network and ISY are busy so it's just that query problem misreporting things, the reality is there aren't that many problems at 3 AM the times where I'm querying throughout the day. Also, while nothing is such that an HA failure will cause damage to my HVAC system, I kind of want my HVAC controls to be reliable and "self healing" when something doesn't work for comms or other reasons, given that insteon does not promise the reliability of a hard wired solution. ISY for its part has been great for reliability and for the self healing aspect when the querying works but the latter does need to work properly for the self healing to work properly. Thinking something is OFF when it's ON causes the system to actually be "self breaking"... For testing purposes I will try disabling all querying for a few days to see what happens, then move to querying only a few times in a day. I'll combine this with some manual "query insteon engine" or scene tests at different times to see if I can uncover (or rule out?) comms issues as the probable cause of these chronic intermittent problems. In the meantime, any other insights and suggestions would be appreciated. Link to comment
Michel Kohanim Posted March 13, 2014 Share Posted March 13, 2014 Hello johnnyt and LeeG, I think it's related to getting two SRX events and not considering it a duplicate. Without having to go through all the discussion, how old/new is this EZIO? With kind regards, Michel Link to comment
johnnyt Posted March 13, 2014 Author Share Posted March 13, 2014 Hello johnnyt and LeeG, I think it's related to getting two SRX events and not considering it a duplicate. Without having to go through all the discussion, how old/new is this EZIO? With kind regards, Michel The one related to the most recent set of posts is only about a week or two old but it is using the older type (design anyway) single band PLM. The first one - at the start of this thread - was maybe a month or so old at that time and had a dual band PLM. Link to comment
johnnyt Posted March 13, 2014 Author Share Posted March 13, 2014 I've been querying insteon engine at various times of the day and so far all have been the same flow of responses with max hops=3, remaining hops=2. This afternoon I ran the command BEFORE opening the event viewer and setting it to level 3. ISY was clearly taxed as response time was quite slow. As part of the responses this time, I got a lot of surprise state changes and two Max Hops=3, Hops Left=0. Could they have been because ISY was busy or is that a clear sign of comm problems, if only for a second or two? I added a space to highlight them. Thu 03/13/2014 04:57:08 PM : [All ] Writing 1 bytes to devices Thu 03/13/2014 04:57:08 PM : [23 8D 7C 0 ] May not fully support i2, reverting to i1 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 1] ST 255 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 5] ST 255 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 6] ST 255 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 8] ST 0 Thu 03/13/2014 04:57:15 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 02 Thu 03/13/2014 04:57:17 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 2B 00 PEEK (00) Thu 03/13/2014 04:57:17 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 03/13/2014 04:57:18 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 02 06 POKE (02) Thu 03/13/2014 04:57:18 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 2B 00 PEEK (00) Thu 03/13/2014 04:57:18 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 04:57:18 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 02 POKE (02) Thu 03/13/2014 04:57:18 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 2] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 3] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 4] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 5] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 6] ST 0 Thu 03/13/2014 04:57:18 PM : [VAR 2 33 ] 301 Thu 03/13/2014 04:57:18 PM : [VAR 2 32 ] 246 Thu 03/13/2014 04:57:19 PM : [VAR 2 12 ] 0 Thu 03/13/2014 04:57:19 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 3F Thu 03/13/2014 04:57:19 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 3F 06 SET-MSB(3F) Thu 03/13/2014 04:57:19 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 3F SET-MSB(3F) Thu 03/13/2014 04:57:19 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:19 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:19 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:20 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 00 PEEK (00) Thu 03/13/2014 04:57:20 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:20 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 03 Thu 03/13/2014 04:57:20 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 03 06 POKE (03) Thu 03/13/2014 04:57:20 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 03 POKE (03) Thu 03/13/2014 04:57:20 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:20 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 0F Thu 03/13/2014 04:57:20 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 0F 06 SET-MSB(0F) Thu 03/13/2014 04:57:21 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 0F SET-MSB(0F) Thu 03/13/2014 04:57:21 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:21 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:21 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:21 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 01 PEEK (01) Thu 03/13/2014 04:57:21 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:21 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 1F Thu 03/13/2014 04:57:21 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 1F 06 SET-MSB(1F) Thu 03/13/2014 04:57:22 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 1F SET-MSB(1F) Thu 03/13/2014 04:57:22 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:22 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:22 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:22 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 02 PEEK (02) Thu 03/13/2014 04:57:22 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:22 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 3F Thu 03/13/2014 04:57:22 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 3F 06 SET-MSB(3F) Thu 03/13/2014 04:57:23 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 3F SET-MSB(3F) Thu 03/13/2014 04:57:23 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:23 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:23 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:23 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 03 PEEK (03) Thu 03/13/2014 04:57:23 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:23 PM : [VAR 2 12 ] -1 Thu 03/13/2014 04:57:24 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 0F Thu 03/13/2014 04:57:24 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 0F 06 SET-MSB(0F) Thu 03/13/2014 04:57:24 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 0F SET-MSB(0F) Thu 03/13/2014 04:57:24 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:24 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:24 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:24 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 01 PEEK (01) Thu 03/13/2014 04:57:24 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:24 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 00 Thu 03/13/2014 04:57:25 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 00 06 POKE (00) Thu 03/13/2014 04:57:25 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 00 POKE (00) Thu 03/13/2014 04:57:25 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:25 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 1F Thu 03/13/2014 04:57:25 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 1F 06 SET-MSB(1F) Thu 03/13/2014 04:57:25 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 1F SET-MSB(1F) Thu 03/13/2014 04:57:25 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:25 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:26 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:26 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 02 PEEK (02) Thu 03/13/2014 04:57:26 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:26 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 00 Thu 03/13/2014 04:57:26 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 00 06 POKE (00) Thu 03/13/2014 04:57:26 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 00 POKE (00) Thu 03/13/2014 04:57:26 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:26 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 3F Thu 03/13/2014 04:57:27 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 3F 06 SET-MSB(3F) Thu 03/13/2014 04:57:27 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 3F SET-MSB(3F) Thu 03/13/2014 04:57:27 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:27 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:27 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:27 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 03 PEEK (03) Thu 03/13/2014 04:57:27 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:27 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 00 Thu 03/13/2014 04:57:28 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 00 06 POKE (00) Thu 03/13/2014 04:57:28 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 00 POKE (00) Thu 03/13/2014 04:57:28 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:30 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 45 01 Thu 03/13/2014 04:57:32 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 45 01 06 IOON (01) Thu 03/13/2014 04:57:32 PM : [ Time] 16:57:31 3(0) Thu 03/13/2014 04:57:32 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 45 8E IOON (8E) Thu 03/13/2014 04:57:33 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 2] ST 255 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 3] ST 255 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 4] ST 255 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 8] ST 255 The log from a few minutes before up to the final state changes tells me that a query of the IOLincs did occur at about the same time (added space before and after the relevant entry). This IOLinc scene being queried does NOT have any EZIO8SA nodes in it. 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Off 0 Thu 2014/03/13 04:47:42 PM Program Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 0% Thu 2014/03/13 04:47:43 PM System Log X10 K8 Thu 2014/03/13 04:48:15 PM System Log X10 K8 Off (11) Thu 2014/03/13 04:48:16 PM System Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Thu 2014/03/13 04:48:22 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 0% Thu 2014/03/13 04:48:22 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) On 255 Thu 2014/03/13 04:48:32 PM Program Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Thu 2014/03/13 04:48:32 PM System Log Scene:1-MISC (Non Lighting) / HVAC / Office Damper for Prgs On Thu 2014/03/13 04:48:35 PM Program Log 1-MISC (Non Lighting) / HVAC / Old Office Damper (for LED) Status 100% Thu 2014/03/13 04:48:35 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 100% Thu 2014/03/13 04:48:35 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Off 0 Thu 2014/03/13 04:49:05 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 04:49:06 PM System Log X10 K8 Thu 2014/03/13 04:56:21 PM System Log X10 K8 On (3) Thu 2014/03/13 04:56:22 PM System Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Thu 2014/03/13 04:56:28 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 100% Thu 2014/03/13 04:56:28 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 100% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HRV / HRV Low-EZIO.5 Status 100% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 100% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 0% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper-EZIO.3 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HRV / HRV Low-EZIO.5 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 On 255 Thu 2014/03/13 04:57:26 PM Program Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 100% Thu 2014/03/13 04:57:31 PM System Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper-EZIO.3 Status 100% Thu 2014/03/13 04:57:31 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 100% Thu 2014/03/13 04:57:31 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Thu 2014/03/13 04:57:31 PM System Log Does this add anything to the story? Link to comment
johnnyt Posted March 13, 2014 Author Share Posted March 13, 2014 Sorry about a third post in a row but here's more data that I'm thinking (hoping) adds to the story. I manually initiated a number of device queries of the EZIO8SA in a row that occurred while an Office Damper scene was being called by a program. Each time the relay response portion of the queries surprised ISY, except for what looks like a duplicate response with max hops=3 remaining hops=0 (separated from the rest in the event viewer excerpt below) 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:22 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:22 PM System Log Scene:1-MISC (Non Lighting) / HVAC / Office Damper for Prgs Off 0 Thu 2014/03/13 05:00:32 PM Program Log 1-MISC (Non Lighting) / HVAC / Old Office Damper (for LED) Status 0% Thu 2014/03/13 05:00:32 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 0% Thu 2014/03/13 05:00:32 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:33 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:34 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:42 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:43 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:50 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:50 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:01:04 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:01:04 PM System Log Thu 03/13/2014 05:00:18 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:18 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:19 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 8E IOCTL (8E) Thu 03/13/2014 05:00:19 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:19 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:19 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:19 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:19 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:19 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:29 PM : [iNST-TX-I1 ] 02 62 00 00 16 CF 13 00 Thu 03/13/2014 05:00:29 PM : [iNST-ACK ] 02 62 00.00.16 CF 13 00 06 LTOFFRR(00) Thu 03/13/2014 05:00:29 PM : [ 15 BB 45 2] ST 0 Thu 03/13/2014 05:00:29 PM : [ 23 8D 7C 4] ST 0 Thu 03/13/2014 05:00:30 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:30 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:30 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:00:30 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:30 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:30 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:31 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:31 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:38 PM : [ Time] 17:00:41 0(0) Thu 03/13/2014 05:00:38 PM : [ Time] 17:00:41 0(0) Thu 03/13/2014 05:00:39 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:39 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:39 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:00:39 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:40 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:40 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 86 IOCTL (86) Thu 03/13/2014 05:00:40 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 03/13/2014 05:00:40 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:40 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:40 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:40 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:41 PM : [ Time] 17:00:44 0(0) Thu 03/13/2014 05:00:41 PM : [ Time] 17:00:44 0(0) Thu 03/13/2014 05:00:45 PM : [VAR 2 66 ] 48 Thu 03/13/2014 05:00:46 PM : [VAR 2 12 ] 1 Thu 03/13/2014 05:00:47 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:47 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:47 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:00:47 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:47 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:47 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:47 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:47 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:47 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:51 PM : [VAR 2 52 ] -820 Thu 03/13/2014 05:00:54 PM : [VAR 2 68 ] 5 Thu 03/13/2014 05:00:55 PM : [VAR 2 58 ] 1837 Thu 03/13/2014 05:00:55 PM : [VAR 2 70 ] 1987 Thu 03/13/2014 05:00:58 PM : [VAR 2 61 ] 2262 Thu 03/13/2014 05:00:58 PM : [ Time] 17:01:01 0(0) Thu 03/13/2014 05:01:00 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:01:00 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:01:01 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:01:01 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:01:01 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:01:01 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:01:01 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:01:01 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:01:01 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:01:03 PM : [ Time] 17:01:05 0(0) Could other activity with error-free comms during a query of the EZIO8SA be at least part of what's causing problems? It would explain the intermittent yet daily occurrence of this kind of problem on a circuit that has only three IOLincs and one EZIO8SA and that is on the same phase as the ISY PLM hanging right off the electrical panel on its own circuit!! Is there anything that ISY firmware changes can fix or somehow accommodate if this is an EZIO8SA problem? Or should I just cut bait and give up on the idea of using insteon for HVAC controls? I've been struggling with this for I think 3 years now, first with IO Lincs (too many it turned out, at least for a solution that tries to be highly reliable and self healing) and now with the EZIO8SA, which, although much more insteon network friendly and efficient for ISY to process has been nothing but trouble (either itself or for ISY or both) from the beginning a short 3-4 months ago and through two units. Link to comment
Michel Kohanim Posted March 14, 2014 Share Posted March 14, 2014 Hi johnnyt, Do you have the problem with both the single as well as dual band PLMs? Hop count of 0 means that the INSTEON packet used all its hops before it got to ISY. This is not about ISY being busy but rather your network is just too busy and perhaps some of the devices are not forwarding the packets. Currently, my worry is that we are getting two identical messages and not considering the second one as duplicate. So, the test I would like done is to continuously query both (perhaps in a program) for about 5 minutes and then send me the output of the Event Viewer. With kind regards, Michel Link to comment
johnnyt Posted March 14, 2014 Author Share Posted March 14, 2014 Hi johnnyt, Do you have the problem with both the single as well as dual band PLMs? Hop count of 0 means that the INSTEON packet used all its hops before it got to ISY. This is not about ISY being busy but rather your network is just too busy and perhaps some of the devices are not forwarding the packets. Currently, my worry is that we are getting two identical messages and not considering the second one as duplicate. So, the test I would like done is to continuously query both (perhaps in a program) for about 5 minutes and then send me the output of the Event Viewer. With kind regards, Michel Yes, with both PLM's, although LeeG pointed out an unexplained message as perhaps being the problem with the dual band that has not been seen with the single band. Attached is the event viewer trace from running the following program: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 150 times Set '1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1' Query Else - No Actions - (To add one, press 'Action') You didn't say you wanted all other programs disabled so I left everything enabled. Let me know if you want me to run it with everything disabled. Repeatedly querying caused one of the self healing programs I have to repeatedly run to turn my HRV to Low (relay 5 of the EZIO8SA). Since it's supposed to be running at this time of the day, that's expected when ISY is surprised to see it isn't. I point to the program in the screenshot below. The four circled programs were stopping and starting repeatedly and should not have been doing that. I let it go for a bit but stopped it part way through the testing. Looking at the trace, relay 6 (HRV High) was also going on and off. It doesn't look to me as though a program was involved but it might have been. When there's a heat call, ISY turns the HRV to high (relay 6 on and relay 5 off). After the heat call ends, it sets the HRV back to low (relay 6 off and relay 5 on). A heat call change is recognizable in the trace because the X10 command K8 would have been heard by the PLM, or IO Linc sensor 15.BB.45 reports a change to OFF (although that's not been reliable, hence the need for X10 backup). I didn't find either of those events in the file. ISY-Events-Log.v4.1.2__Fri 2014.03.14 02.50.07 PM.txt Link to comment
Michel Kohanim Posted March 14, 2014 Share Posted March 14, 2014 Hi johnnyt, Nothing was attached. With kind regards, Michel Link to comment
johnnyt Posted March 15, 2014 Author Share Posted March 15, 2014 Hi Michel, it's just above the screenshot. I just successfully downloaded it. edit: it shows it's been downloaded 4 times as of 8:47 PM EDT on Mar 14th Link to comment
LeeG Posted March 15, 2014 Share Posted March 15, 2014 It looks like the Scene which is turning on Relay 5 does not actually turn On the Relay. There are a number of places where this Scene is used but the Relay never actually turns On. The Red line marks the ISY Status of Relay 5 as On but the Query done immediately after shows the Scene did not work as Relay 5 is Off from the Query results. Same thing happens in other areas in the trace. Fri 03/14/2014 02:44:42 PM : [iNST-TX-I1 ] 02 62 00 00 1F CF 11 00 Fri 03/14/2014 02:44:42 PM : [iNST-ACK ] 02 62 00.00.1F CF 11 00 06 LTONRR (00) Fri 03/14/2014 02:44:42 PM : [ 23 8D 7C 5] ST 255 Fri 03/14/2014 02:44:42 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Fri 03/14/2014 02:44:42 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Fri 03/14/2014 02:44:43 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 01 IOCTL (01) Fri 03/14/2014 02:44:43 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/14/2014 02:44:43 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Fri 03/14/2014 02:44:43 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Fri 03/14/2014 02:44:44 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Fri 03/14/2014 02:44:44 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/14/2014 02:44:44 PM : [ 23 8D 7C 5] ST 0 Link to comment
johnnyt Posted March 15, 2014 Author Share Posted March 15, 2014 so what does that mean? could the EZIO PLM be overwhelmed by the query command? a few posts back the "query insteon engine" I ran trumped a device query I also ran while the first one was still running. Or is it because the insteon network was busy at that one moment and caused the scene command to have been completely missed by the EZIO PLM? I believe scene commands only go out once, right? Does collision avoidance not prevent scene commands from getting lost like that? Link to comment
LeeG Posted March 15, 2014 Share Posted March 15, 2014 A Scene On/Off in the ISY is a single command that is not ACKed by the Responders. Much like an X10 command goes out on Insteon network without any ACKs. The 00.00.1F Scene On appears 8-9 times in the event trace and it never actually causes the Relay to turn On. None of the Query Relay responses shows Relay 5 On anywhere in the trace. Fri 03/14/2014 02:46:28 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Fri 03/14/2014 02:46:28 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Fri 03/14/2014 02:46:28 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 01 IOCTL (01) Only Relay 1 shows as On. Hard to know if the flood of Query commands is the issue or Scenes are not working well going to the EZIO8SA. Could put a Wait of a few seconds in the Repeat loop to see if Relay 5 every shows On in the Query Relay response. Search the event trace for 00.00.1F which is the Scene to turn On Relay 5. Then look at the Query Relay response (example above) and see that only Relay 1 ever shows as On. Link to comment
LeeG Posted March 15, 2014 Share Posted March 15, 2014 There is another possibility, the EZIO8SA has lost a link record. The Query commands are showing good communication between the PLM and the EZIO8SA. If the EZIO8SA did not know it should respond to Scene 00.00.1F because the link record was missing there would be no errors since there is no ACK. The PLM has the link for Scene 00.00.1F, otherwise the Scene On would have been rejected. Could try a Scene Test for that Scene. The PLM issues different commands for a Scene Test which do require ACKs. If the EZIO8SA fails to react the Scene Test will show a failure for that device. Link to comment
johnnyt Posted March 15, 2014 Author Share Posted March 15, 2014 Did three different scene tests, HRV Low, HRV High, and HRV Off. All succeeded according to event traces (2 of 3 attached), however the HRV does NOT turn on, so there's definitely something wrong I checked the device links three times and each time only got one record - see attached screenshot. I did see this when I first installed it (using "replace with" to copy from the original dual band PLM), but fixed it with a "restore device". So it seems the PLM loses it's links. But then how come the scene tests worked??? I'll do the restore device again, repeat a bunch of tests (later today) and report back. On a side note, strangely (to me) the scene test causes the event viewer to be cleared. I don't know if this is by design but I learned you have to save what's there before you run a test if you want to keep it. ISY-Events-Log.v4.1.2_SceneHRVHigh.txt ISY-Events-Log.v4.1.2__SceneHRVLow.txt Link to comment
johnnyt Posted March 15, 2014 Author Share Posted March 15, 2014 I did the device restore until I got an identical compare with ISY links table. It took 2 attempts as the first one had 2 record mismatches. I think that's happen to me before with a KPL (lots of links) so I presume it's not an indication of a malfunctioning device. I then ran a few manual device queries of the EZIO8SA and it looks like a duplicate response occurred that may have set off some problems with the state ISY had internally for relays 1 then 5. Relay 1 repeatedly surprises ISY with its ON state. See attachment that ends in "DeviceQuery-relay1ONalready.txt" I did it again, this time watching the state of relay 1 in the GUI, which was ON to start. I would see the star come up beside it and it stayed ON. The trace shows ISY is actually surprised to hear the relay is ON.. twice! See attachment that ends in "DeviceQuery-Relay1ON-2.txt". A visual check of the dampers being controlled confirmed they were physically ON. I also ran the program that does 150 repeated queries. All seems fine until mid way through when the following extended response occurs: Sat 03/15/2014 02:44:31 PM : [iNST-ERX ] 02 51 23 8D 7C 24 1B FE 12 79 B8 CF 32 BD 43 FF FF 1F FF EF FF F0 00 00 AF Sat 03/15/2014 02:44:31 PM : [Ext-Direct ] 23.8D.7C-->ISY/PLM Group=0, Max Hops=2, Hops Left=0 Soon after the INST-ERX message appears a response (in red below) that's interrupting the normal flow of responses seen both before and again later. Sat 03/15/2014 02:44:32 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sat 03/15/2014 02:44:32 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sat 03/15/2014 02:44:32 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 21 IOCTL (21) Sat 03/15/2014 02:44:32 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sat 03/15/2014 02:44:33 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sat 03/15/2014 02:44:33 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/15/2014 02:44:33 PM : [ 23 8D 7C 1] ST 0 For the next several queries relays 1, 4, 6 and 7 are reported as having changed, with each changing back to (I assume) its actual state all along. Aside from wondering about what seems like a duplicate response that throws a lot of things off, and wondering why ISY seems to be surprised that relay 1 is ON when it shows it as ON in the GUI as well as in prior query responses, I'm wondering why the ERX message only shows up once in 150 queries. Or, maybe the question is why is there an ERX message at all? Any info would be appreciated. ISY-Events-Log.v4.1.2__150queries.txt ISY-Events-Log.v4.1.2__DeviceQuery-relay1ONalready.txt ISY-Events-Log.v4.1.2__DeviceQuery-Relay1ON-2.txt Link to comment
Michel Kohanim Posted March 16, 2014 Share Posted March 16, 2014 Hi LeeG, as always your sharp eyes have caught something that I had not even paid attention to. Hi johnnyt, I guess I need new glasses. Thanks so very much for the details. I do not see anything that strikes me as strange. One question though: do you have any scenes where two or more inputs or outputs of EZIO are members of? Perhaps it would be best to have submit a ticket so that we can login to your computer and see everything as it happens. With kind regards, Michel Link to comment
johnnyt Posted March 17, 2014 Author Share Posted March 17, 2014 One question though: do you have any scenes where two or more inputs or outputs of EZIO are members of? Yes I have at least three and they work under normal conditions. If I may I’d like to ask what you're thinking might need fixing because it’s not clear to me, particularly given the comment that you "do not see anything that strikes (you) as strange". From where I sit there a number of problems, some seeming to be ISY logic or something ISY could compensate for, others seeming to be problems with the EZIO8SA. The problem with the latter is explaining to Smartenit that the problem is not an ISY issue as right now they don’t seem to take any ownership for the behavior I’m seeing. Which of these problems do you think you might be able to fix or be able to rule out ISY as involved in it or be able to compensate for: 1) relays intermittently yet frequently surprising ISY even when they are already in the reported state (relay 1 being a pretty consistent offender) 2) on query, relays periodically surprising ISY with wrong state then if queried again reversing to actual state (because of extra messages?) 3) scene commands that often don't work during EZIO8SA queries 4) relays that end up stuck ON until EZIO8SA relay unit is power cycled 5) device link DB getting wiped out (according to ISY Device links query) but with some stuff still working 6) The bad sequence, seen when I was using Dual Band PLM viewtopic.php?f=27&t=13528#p106690 viewtopic.php?f=27&t=13528#p106758 7) this: viewtopic.php?f=27&t=13528&start=15#p108872, which I can't figure out how to summarize I’m trying to assess whether this actually has the potential to end well. If all you’re looking at and might fix is, say, number 1, it won’t be enough for me to think the EZIO8SA is going to work out for me. Link to comment
Michel Kohanim Posted March 18, 2014 Share Posted March 18, 2014 One question though: do you have any scenes where two or more inputs or outputs of EZIO are members of? Yes I have at least three and they work under normal conditions. This is where I beg to differ. I think what you are experiencing are "normal conditions" and what you wish them to do are the exceptions. You cannot have multiple IO outputs in the same scene. It does not work. ISY may think that EZIO (like KPL) would be able to respond to one scene command that turns multiple relays on, but ISY is mistaken. The only way you can send a scene command to turn multiple outputs on/off simultaneously requires changing the way we do things (or using SmartenIt utility). So, before spending more time going through logs and events, may I humbly suggest having one relay/output per scene? With kind regards, Michel Link to comment
johnnyt Posted March 19, 2014 Author Share Posted March 19, 2014 You cannot have multiple IO outputs in the same scene. Well isn't that special! This is probably the 6th undocumented feature of the EZIO8SA I've encountered, and by far the most expensive one. This morning I changed the 3 scenes I had that contained multiple relays and adjusted the handful of programs that called them so they activated each relay separately. It's been about 12 hours and my inbox does not have a single notification of problems related to relay status surprises. While I've had the odd "good day" like this so I'm going to have to wait a few days to declare victory, I am quite optimistic. This could certainly explain the intermittent nature of the problem with the problems showing up only after some program had called one of the problematic scenes. I also have to wait to see if this solves the problems such as 5 and 6 on my list, which have happened only twice in ~3 months. I will confirm the one thing it has NOT fixed. ISY continues to be surprised by the state of relay 1. For example, the ISY GUI showed relay 1 was ON when I queried the device yet ISY recorded it as a status change to ON. Tue 03/18/2014 08:24:57 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Tue 03/18/2014 08:24:57 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Tue 03/18/2014 08:24:57 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 03 IOCTL (03) Tue 03/18/2014 08:24:57 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 03/18/2014 08:24:57 PM : [ 23 8D 7C 1] ST 255 Tue 03/18/2014 08:24:57 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Tue 03/18/2014 08:24:57 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Tue 03/18/2014 08:24:57 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Tue 03/18/2014 08:24:57 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 I'm not going to ask you if this can be fixed because 1) I don't have any programs that are triggered based only on relay 1 status and 2) if needed, I can work around the issue by picking a different relay and I'd rather see UDI work on 4.x and 5.0 releases. I did want to mention it in case it can help someone else. Perhaps I'll also publish a list of EZIO8SA undocumented features if this ends well to save others a lot of grief. Link to comment
Michel Kohanim Posted March 19, 2014 Share Posted March 19, 2014 Hi johnnyt, I am so very sorry that you had to go through this and, to be honest, I wouldn't have been able to pinpoint the issue had I not gone through a similar thing just a week ago. The log you are showing is NOT that ISY is surprised. The event viewer is what it is: for viewing events and ISY is merely showing you what the event means and NOT what should be on the UI (both of which are correct in this case). With kind regards, Michel Link to comment
johnnyt Posted March 21, 2014 Author Share Posted March 21, 2014 The log you are showing is NOT that ISY is surprised. The event viewer is what it is: for viewing events and ISY is merely showing you what the event means and NOT what should be on the UI (both of which are correct in this case). Okay, I get it. Sort of. I tested other devices and sure enough querying a device returns it's state and programs with the device will be evaluated even if the reported state is not a change. What confuses me, though, is why isn't the state of all 8 EZIO8SA relays reported back given that a query of node 1 is a query of all nodes? Or to ask a slightly different question, how would I get the same effect, i.e. cause a program evaluation from a query, for relays 2-8 of the EZIO8SA? Link to comment
LeeG Posted March 21, 2014 Share Posted March 21, 2014 The Query Relay reports the status of all relays. The value in cmd2 (0x86) is a bit map which shows all relays starting with Relay 1 in the right most bit. In this response Relay 2,3 and 8 are On. Thu 03/13/2014 05:00:30 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:30 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:30 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:00:30 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 1] ST 0 EDIT: a KeypadLinc works the same. The ISY sends a Query command for the first node only. The response from the KeypadLinc is a bit map reflecting the state of all the KPL buttons. Link to comment
johnnyt Posted March 21, 2014 Author Share Posted March 21, 2014 The Query Relay reports the status of all relays. The value in cmd2 (0x86) is a bit map which shows all relays starting with Relay 1 in the right most bit. Yes, I realize that (thanks to you and your post early in the thread). I guess I was wondering two things. 1. Why doesn't the event viewer show something like this when queried? Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 2] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 3] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 4] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 5] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 6] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 7] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 8] ST 0 2. Does a program with one of the relays 2-8 evaluate when node 1 is queried The first one certainly would have helped my troubleshooting and would have avoided some questions and logical conclusions I drew. For number 2, I just created a test program with only status of relay 2 as the trigger and it works fine. I guess I knew this since when things worked well (i.e. no problems caused by multi-device scenes being called) programs with relays 2-7 did work fine. So I take the 2nd question in my last post back... Link to comment
LeeG Posted March 21, 2014 Share Posted March 21, 2014 Ignoring what happens to Relay 1 (will cover that at the end) the Query Status/State of each relay is displayed when it is different from what the ISY has for the relays current Status. I turned all the relays On using a Utility so the ISY would have them Off when they were actually On when the Query was done. Then I turned them Off with a Utility so the ISY would have them On when they were actually Off. In both cases the ISY displayed the state of all the Relays because the Query response showed a change for each relay. Fri 03/21/2014 09:12:44 AM : [iNST-TX-I1 ] 02 62 0D FC 71 0F 4F 02 Fri 03/21/2014 09:12:44 AM : [iNST-ACK ] 02 62 0D.FC.71 0F 4F 02 06 IOCTL (QUERY) Fri 03/21/2014 09:12:44 AM : [iNST-SRX ] 02 50 0D.FC.71 22.80.0B 2B 4F FF IOCTL (FF) Fri 03/21/2014 09:12:44 AM : [std-Direct Ack] 0D.FC.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/21/2014 09:12:44 AM : [ D FC 71 1] ST 255 Fri 03/21/2014 09:12:44 AM : [ D FC 71 2] ST 255 Fri 03/21/2014 09:12:44 AM : [ D FC 71 3] ST 255 Fri 03/21/2014 09:12:44 AM : [ D FC 71 4] ST 255 Fri 03/21/2014 09:12:44 AM : [ D FC 71 5] ST 255 Fri 03/21/2014 09:12:44 AM : [ D FC 71 6] ST 255 Fri 03/21/2014 09:12:44 AM : [ D FC 71 7] ST 255 Fri 03/21/2014 09:12:44 AM : [ D FC 71 8] ST 255 Fri 03/21/2014 09:12:44 AM : [iNST-TX-I1 ] 02 62 0D FC 71 0F 49 00 Fri 03/21/2014 09:12:47 AM : [iNST-ACK ] 02 62 0D.FC.71 0F 49 00 06 RINPUT (00) Fri 03/21/2014 09:12:47 AM : [iNST-SRX ] 02 50 0D.FC.71 22.80.0B 2B 49 31 RINPUT (31) Fri 03/21/2014 09:12:47 AM : [std-Direct Ack] 0D.FC.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/21/2014 09:12:47 AM : [ D FC 71 9] ST 255 Fri 03/21/2014 09:13:34 AM : [iNST-TX-I1 ] 02 62 0D FC 71 0F 4F 02 Fri 03/21/2014 09:13:34 AM : [iNST-ACK ] 02 62 0D.FC.71 0F 4F 02 06 IOCTL (QUERY) Fri 03/21/2014 09:13:35 AM : [iNST-SRX ] 02 50 0D.FC.71 22.80.0B 2B 4F 00 IOCTL (00) Fri 03/21/2014 09:13:35 AM : [std-Direct Ack] 0D.FC.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/21/2014 09:13:35 AM : [ D FC 71 1] ST 0 Fri 03/21/2014 09:13:35 AM : [ D FC 71 2] ST 0 Fri 03/21/2014 09:13:35 AM : [ D FC 71 3] ST 0 Fri 03/21/2014 09:13:35 AM : [ D FC 71 4] ST 0 Fri 03/21/2014 09:13:35 AM : [ D FC 71 5] ST 0 Fri 03/21/2014 09:13:35 AM : [ D FC 71 6] ST 0 Fri 03/21/2014 09:13:35 AM : [ D FC 71 7] ST 0 Fri 03/21/2014 09:13:35 AM : [ D FC 71 8] ST 0 Now to Relay 1. I think the ISY displaying Relay 1 state and actually triggering a Program as though Status changed when it did not is a defect. Displaying the State when it did not change could be considered okay since this is an event trace. However, triggering a Program when the Status did not change has to be a bug (IMO). This trace shows a Program being triggered that is using If Status even though Status did not change. Fri 03/21/2014 09:35:46 AM : [iNST-TX-I1 ] 02 62 0D FC 71 0F 4F 02 Fri 03/21/2014 09:35:46 AM : [iNST-ACK ] 02 62 0D.FC.71 0F 4F 02 06 IOCTL (QUERY) Fri 03/21/2014 09:35:46 AM : [iNST-SRX ] 02 50 0D.FC.71 22.80.0B 2B 4F 00 IOCTL (00) Fri 03/21/2014 09:35:46 AM : [std-Direct Ack] 0D.FC.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/21/2014 09:35:46 AM : [ D FC 71 1] ST 0 Fri 03/21/2014 09:35:46 AM : [ X10] A12 Fri 03/21/2014 09:35:46 AM : [ X10] A12/Off (11) Fri 03/21/2014 09:35:46 AM : [iNST-TX-I1 ] 02 62 0D FC 71 0F 49 00 Fri 03/21/2014 09:35:47 AM : [X10-RSP ] 02 63 6B 00 06 Fri 03/21/2014 09:35:48 AM : [X10-RSP ] 02 63 63 80 06 Fri 03/21/2014 09:35:48 AM : [X10-RX ] 02 52 6B 00 Fri 03/21/2014 09:35:48 AM : [ X10] A12 Fri 03/21/2014 09:35:49 AM : [iNST-ACK ] 02 62 0D.FC.71 0F 49 00 06 RINPUT (00) Fri 03/21/2014 09:35:49 AM : [iNST-SRX ] 02 50 0D.FC.71 22.80.0B 2B 49 30 RINPUT (30) Fri 03/21/2014 09:35:49 AM : [std-Direct Ack] 0D.FC.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/21/2014 09:36:03 AM : [iNST-TX-I1 ] 02 62 0D FC 71 0F 4F 02 Fri 03/21/2014 09:36:03 AM : [iNST-ACK ] 02 62 0D.FC.71 0F 4F 02 06 IOCTL (QUERY) Fri 03/21/2014 09:36:03 AM : [iNST-SRX ] 02 50 0D.FC.71 22.80.0B 2B 4F 00 IOCTL (00) Fri 03/21/2014 09:36:03 AM : [std-Direct Ack] 0D.FC.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 03/21/2014 09:36:03 AM : [ D FC 71 1] ST 0 Fri 03/21/2014 09:36:03 AM : [ X10] A12 Fri 03/21/2014 09:36:03 AM : [ X10] A12/Off (11) Fri 03/21/2014 09:36:03 AM : [iNST-TX-I1 ] 02 62 0D FC 71 0F 49 00 Fri 03/21/2014 09:36:03 AM : [X10-RSP ] 02 63 6B 00 06 Fri 03/21/2014 09:36:04 AM : [X10-RSP ] 02 63 63 80 06 Fri 03/21/2014 09:36:05 AM : [X10-RX ] 02 52 6B 00 Fri 03/21/2014 09:36:05 AM : [ X10] A12 Fri 03/21/2014 09:36:05 AM : [iNST-ACK ] 02 62 0D.FC.71 0F 49 00 06 RINPUT (00) Fri 03/21/2014 09:36:06 AM : [iNST-SRX ] 02 50 0D.FC.71 22.80.0B 2B 49 30 RINPUT (30) Fri 03/21/2014 09:36:06 AM : [std-Direct Ack] 0D.FC.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 If Status 'EZIO8SA' is Off Then Send X10 'A12/Off (11)' Else Send X10 'A10/On (3)' Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.