Chris Jahn Posted April 18, 2016 Posted April 18, 2016 Hello Chris, Thanks so very much. We were wondering why the logs showed the scene being turned on three times. You have answered that. Is there a rule that can be generalized from this? Is it that the statements in the IF are processed in order (I don't think this is the case)? Or something else? Al Hi Al, The general rules are: - Each individual event can trigger a program to run - Each event is processed in the order in which it is created - The If conditions in programs are evaluated for every single event (i.e. If there are 3 events, the if conditions will be evaluated 3 times) Therefore in your case, even though the initial 'DON' event caused the program to run the Then path, updating the target light value in programs wouldn't occur until after the other two 'ST' events were processed. Thus, when the other two 'ST' values were processed the target light value in programs is still considered Off. Events were created in this order: DON - motion sensor ST 255 - motion sensor light 1 ST 255 - motion sensor light 2 ST 255 - target light value
Algorithm Posted April 18, 2016 Posted April 18, 2016 Hi Al, The general rules are: - Each individual event can trigger a program to run - Each event is processed in the order in which it is created - The If conditions in programs are evaluated for every single event (i.e. If there are 3 events, the if conditions will be evaluated 3 times) Therefore in your case, even though the initial 'DON' event caused the program to run the Then path, updating the target light value in programs wouldn't occur until after the other two 'ST' events were processed. Thus, when the other two 'ST' values were processed the target light value in programs is still considered Off. Events were created in this order: DON - motion sensor ST 255 - motion sensor light 1 ST 255 - motion sensor light 2 ST 255 - target light value Hi Chris, thank you. So basically, all the IF conditions are processed before anything resulting from that (occurring in THEN or ELSE) is updated? That's good information; it may perhaps prove useful to others in the future. Al
larryllix Posted April 18, 2016 Posted April 18, 2016 Larry, it's usually not difficult to change/eliminate a firmware command. UDI updates firmware quite often. It's not a drastic change and the basic firmware is the same on virtually every Insteon controller, one change works for all. There is no evidence that the problem extends beyond the ISY994. I haven't even seen a ISY99 user report an ALL ON. A possible explanation is that the ISY994 is so smart that it can detect a signal that no other Insteon manger can see I have worked in industry and I know better than that. Meetings, decisions, planning, assignment, writing the changes, proofreading by third parties, writing test software/procedures to proof it, proofing it and other testing, prototyping, and final approvals for the next production runs. I don't see UDI putting out minor changes every week either. It costs big bucks. Maybe some companies do but I doubt SH would have gotten this far on products that frequently ruin their name. After all that, some screw-ups still slip by the whole process and customers start complaining. Now you have personnel to handle all that, compile it into common elements and present to the decision board again. In very critical software, the accepted throughput speed is one line of code per day but some space shuttles still kill all the occupants.. Maybe I just worked where zero tolerance for errors was the rule for too long. The embarrassment would spread like wildfire throughout the industry, not to mention the penalties issued.
mwester Posted April 19, 2016 Posted April 19, 2016 I have worked in industry and I know better than that. Meetings, decisions, planning, assignment, writing the changes, proofreading by third parties, writing test software/procedures to proof it, proofing it and other testing, prototyping, and final approvals for the next production runs. I don't see UDI putting out minor changes every week either. It costs big bucks. Maybe some companies do but I doubt SH would have gotten this far on products that frequently ruin their name. After all that, some screw-ups still slip by the whole process and customers start complaining. Now you have personnel to handle all that, compile it into common elements and present to the decision board again. In very critical software, the accepted throughput speed is one line of code per day but some space shuttles still kill all the occupants.. Maybe I just worked where zero tolerance for errors was the rule for too long. The embarrassment would spread like wildfire throughout the industry, not to mention the penalties issued. Having worked very close to the software release teams for numerous organizations shipping all sorts of products, I can see both points-of-view... Larry is right; my experience with companies such as those in the auto industry is similar in terms of the decision process as well as the productivity and costs. One of the huge factors for these industries is the cost and difficulty of updating firmware or replacing devices if they get it wrong. On the other hand, the current "best practice" is termed 'agile development', which is all about pushing updates fast and furious -- a two-week development "sprint" is the goal, with the product expected to be ready-to-ship at the end of each two-week sprint. This is a great way to do software updates for things like web-based portals. Not only does it allow getting competitive features to market fast, it also helps smart companies stay ahead of security vulnerabilities by getting fixes pushed out quickly. The issue with Smart Home is that their product clearly falls into the first camp in that it's impossible to update the firmware. However, they seem to modify the firmware almost "ad-hoc", without documentation or notification, and seemingly without adequate testing. So, I can see that it's possible Smart Home "knows something" about the all-off problem, and therefore they've gone to the lengths of disabling that feature and updating all their internal testing processes to account for it, etc, etc. On the other hand, it's equally possible one of their engineers just commented out a line or two of code, did some cursory ad-hoc testing, checked in the source code, and said, "no problem, we'll see if anyone notices, and hope this doesn't break anything -- gotta run, surf's up!" Edited to add: I overlooked one of the key aspects of the agile methodology -- which is to get user feedback and user testing in each and every two-week sprint. You tell me if y'all think Smart Home gets users involved in the firmware changes
stusviews Posted April 19, 2016 Posted April 19, 2016 I never said it was a snap decision. SH learned about the ALL ON considerably more than a year before the change was actually implemented.
apostolakisl Posted April 22, 2016 Posted April 22, 2016 Just had my very first all on event. It happened instantly as a pressed the off paddle of a switchlink. as if the off paddle was linked to an all on signal. The scene included 4 switchlinks and does not trigger any programs. These switchlinks are all relatively old, probably 3 years old.
stusviews Posted April 22, 2016 Posted April 22, 2016 Just had my very first all on event. It happened instantly as a pressed the off paddle of a switchlink. as if the off paddle was linked to an all on signal. The scene included 4 switchlinks and does not trigger any programs. These switchlinks are all relatively old, probably 3 years old. Provide details for the PLM, device you tapped and scene members, for example, four digit date codes on the printed labels and versions as reported by the ISY for anyone who's keeping track.
apostolakisl Posted April 22, 2016 Posted April 22, 2016 I pushed the off paddle on a 2476D v38 dimmer w/beeper. This does not show up in the ISY log nor does any of this. I pushed the off paddle of a switchlinc right next to it a second before, and that does show up along with the other devices in its scene. There is also another v38 and a v37 and a dual band v41 in that scene. The dual band is of course the newest member and I want to say it is about 1.5 years old. Date codes would require pulling the switches. I don't really feel like doing that right now. ISY did not know that all the devices turned on. It was not in the log and the status of all the devices in the isy console does not reflect the on event.
LeeG Posted April 22, 2016 Posted April 22, 2016 "I pushed the off paddle on a 2476D v38 dimmer w/beeper. " The paddle press not showing in the ISY Log or an Event Trace if active is not part of an All On event. That suggests a comm issue or link record problem. The normal All On event where all devices turn On does not appear in the ISY Log or event trace. However, the device action that started the All On (paddle, button, battery powered device) does appear in the ISY Log and event trace.
apostolakisl Posted April 22, 2016 Posted April 22, 2016 "I pushed the off paddle on a 2476D v38 dimmer w/beeper. " The paddle press not showing in the ISY Log or an Event Trace if active is not part of an All On event. That suggests a comm issue or link record problem. The normal All On event where all devices turn On does not appear in the ISY Log or event trace. However, the device action that started the All On (paddle, button, battery powered device) does appear in the ISY Log and event trace. I've pushed that paddle a dozen times a day for several years and never had an all on event before and I have pushed it several times since the all on event. I don't know how a com issue would cause an all on event or how a link table problem would be a one-off problem. There are two switchlincs in that double gang box right next to each other. I pressed one, then a split second later pressed the other. The all-on coincided with pushing the second, but it could be that there was a split second delay from pressing the paddle to seeing the all-on and it was actually my pressing the first paddle that did it. The press of the first paddle does all show up in the log as does the scene responders. This is the log starting wiht an event at 10:51:08 that is well before the all-on. Then you see the 4 devices in the Kitchen, that is the first paddle I pressed. That particular button does trigger a program which changes the status of some kpl buttons which you also see in the log. ?Maybe that has something to do with it? Perhaps when I hit the second off paddle, the system was in the midst of going haywire so that paddle press got lost in the noise? Then about 30 seconds later I used the "all off" button from the admin console and I included some of that in the log below also. Master Bedroom / Master-Bath Chand L Status 0% Thu 2016/04/21 10:51:08 PM System Log Kitchen / Kitchen Intercom-Puck L Status 0% Thu 2016/04/21 10:53:57 PM System Log Kitchen / Kitchen Micro-Puck Status 0% Thu 2016/04/21 10:53:57 PM System Log Kitchen / Kitchen Corner-Puck Status 0% Thu 2016/04/21 10:53:57 PM System Log Master Bedroom / Master-Keypad / Mstr Bed Key A Kitchen S Status 0% Thu 2016/04/21 10:53:57 PM System Log Scene:Master Keypad B On 255 Thu 2016/04/21 10:53:57 PM Program Log Scene:Master keypad A Off 0 Thu 2016/04/21 10:53:58 PM Program Log X10 A2 Thu 2016/04/21 10:54:02 PM System Log X10 A2 Off (11) Thu 2016/04/21 10:54:03 PM System Log A10 a2 1 Status 0% Thu 2016/04/21 10:54:03 PM System Log X10 A2 Thu 2016/04/21 10:54:03 PM System Log X10 A2 Off (11) Thu 2016/04/21 10:54:04 PM System Log Evans Room / Evans Rm-Overhead L On 12 Thu 2016/04/21 10:54:27 PM Program Log Evans Room / Evans Rm-Overhead L Status 5% Thu 2016/04/21 10:54:28 PM System Log Alexis Room / Alexis BR-Overhead L On 63 Thu 2016/04/21 10:54:29 PM Program Log Alexis Room / Alexis BR-Overhead L Status 25% Thu 2016/04/21 10:54:30 PM System Log Scene:My Lighting Fast Off Thu 2016/04/21 10:54:30 PM Web Log Kitchen / Kitchen Intercom-Island L Status 0% Thu 2016/04/21 10:54:31 PM System Log Kitchen / Kitchen corner-Island Status 0% Thu 2016/04/21 10:54:31 PM System Log Master Bedroom / Master-Keypad / Mstr Bed Key B all off Status 0% Thu 2016/04/21 10:54:31 PM System Log Kitchen / Kitchen Micro-Island Status 0% Thu 2016/04/21 10:54:31 PM System Log Family Room / Family Room-Ceiling L Status 0% Thu 2016/04/21 10:54:31 PM System Log Upstairs Hall / Upstairs-Arches L Status 0% Thu 2016/04/21 10:54:31 PM System Log Foyer / Foyer-Stairs L Status 0% Thu 2016/04/21 10:54:31 PM System Log Back Hall / Back Hall Ext Door-Breezway Status 0% Thu 2016/04/21 10:54:31 PM System Log Garage / Third Garage-Breez L Status 0% Thu 2016/04/21 10:54:31 PM System Log Living Room / Living Rm-Piano L Status 0% Thu 2016/04/21 10:54:31 PM System Log Dining Room / Dining Room-China Cab L Status 0% Thu 2016/04/21 10:54:31 PM System Log Foyer / Foyer-Niche L Status 0% Thu 2016/04/21 10:54:31 PM System Log Foyer / Foyer-Coach L Status 0% Thu 2016/04/21 10:54:31 PM System Log Foyer / Foyer-Portico Can L Status 0% Thu 2016/04/21 10:54:31 PM System Log Master Bedroom / Master-Window Lmp L Status 0% Thu 2016/04/21 10:54:31 PM System Log Living Room / Cabinet L Status 0% Thu 2016/04/21 10:54:31 PM System Log Foyer / Foyer@Stairs-Chandalier / Foyer@Stairs-Upstairs Arches Status 0% Thu 2016/04/21 10:54:31 PM System Log Living Room / Living Rm-Eyeball L Status 0% Thu 2016/04/21 10:54:31 PM System Log Alexis Room / Alexis BR-Overhead L Status 0% Thu 2016/04/21 10:54:31 PM System Log Kitchen / Kitchen-Over Sink L Status 0% Thu 2016/04/21 10:54:31 PM System Log Living Room / Living Rm-Couch Lamps L Status 0% Thu 2016/04/21 10:54:31 PM System Log Foyer / Foyer-Mstr Vestibule Nook L Status 0% Thu 2016/04/21 10:54:31 PM System Log Playroom / Play Room-Deck Door-Porch Coa / Play Room-Deck Door.D Status 0% Thu 2016/04/21 10:54:31 PM System Log .
LeeG Posted April 22, 2016 Posted April 22, 2016 Sorry, I did not cover that well. The lack of an ISY Log entry or lack of event trace entry from a paddle press is what I was referring to as a comm issue or link record question. I have never seen an All On, as many other ISY users have not seen an All On. The All On is the result of a malformed Insteon message that seems to happen when certain Insteon messages overlap.
apostolakisl Posted April 22, 2016 Posted April 22, 2016 Sorry, I did not cover that well. The lack of an ISY Log entry or lack of event trace entry from a paddle press is what I was referring to as a comm issue or link record question. I have never seen an All On, as many other ISY users have not seen an All On. The All On is the result of a malformed Insteon message that seems to happen when certain Insteon messages overlap. I had never seen it until yesterday myself. Thought I got lucky, guess at least I don't have it as bad as others. I did press two paddles in relatively quick succession, so an overlap is certainly a possibility. I don't typically have any com issues with that switch, and the other paddle right next to it pressed but a split second earlier certainly did not. So I am presently favoring your belief that it can be the result of an overlap. Those two switches get pressed in quick succession on a regular basis, so if it is an issue of timing/overlap, it might be that you have to catch it just on the specific power line cycle.
dstanley Posted April 22, 2016 Author Posted April 22, 2016 This latest issue with apostolakisl makes me wonder how the ISY could possibly be accused as the culprit of the All-On scenarios? From what everybody is saying/thinking/reading is that this All-On does not occur using 'other' controllers and it is somehow ISY related. This latest 'trigger' seems to have nothing to do with the ISY or Motion Senor as is commonly believed to be the main instigators of this issue. Just something else to ponder ... Dwight
LeeG Posted April 22, 2016 Posted April 22, 2016 I agree completely that the timing of the overlap is critical in creating the overlap. If the two SwitchLinc's have Responders I can see where an inbound ACK could happen at the same time an outbound message is happening. It is easier to see from a device like a Motion Sensor that is not monitoring the powerline could overlap something. Dwight This is not an ISY failure. SmartLabs would not change the design of PLM and other devices to fix an ISY failure. Devices like the Hub do not have the capability of producing the complex activity possible with an ISY.
Techman Posted April 22, 2016 Posted April 22, 2016 Is it possible that the PLM was not originally designed to handle the volume of data coming from the ISY?
dstanley Posted April 22, 2016 Author Posted April 22, 2016 I am still using the 'test' PLM supplied by Michel in my system and I have had at least three All-On events using this PLM. I have since modified my system (removed a motion sensor even though it had no devices or scenes linked to it) and modified some programs on my garage doors to try to minimize the events. As soon as my budget allows I will be removing the ioLincs from my garage door openers as every event seemed to be triggered by the opening of one of the garage doors (in my instance anyways). I am hoping to replace the ioLincs with Linear GD00Z-4 Zwave Garage Door Controllers in the future. Dwight
LeeG Posted April 22, 2016 Posted April 22, 2016 Dwight I'm not familiar with the firmware in the "test PLM". UDI cannot supply custom PLM firmware, it has to be produced by SmartLabs. Also if All On was only related to the PLM alone SmartLabs would not be adjusting other Insteon devices.
ScottAvery Posted June 9, 2016 Posted June 9, 2016 Going on six years in, last night I had my first ALL ON, garage door opener, space heaters, and all. I thought I was immune, but no such luck. It surprised me that even new devices turned on, as I thought All ON has long been removed from the protocol. No buttons were pushed, it happened due to my sunset program that has run unaltered for years. Didn't bother logging in to check the logs, yet. Curious to see what happens tonight.
stusviews Posted June 9, 2016 Posted June 9, 2016 The ALL ON phenomenon is rarely, if ever, able to be replicated. That's what makes it so difficult to solve.
Teken Posted June 9, 2016 Posted June 9, 2016 Going on six years in, last night I had my first ALL ON, garage door opener, space heaters, and all. I thought I was immune, but no such luck. It surprised me that even new devices turned on, as I thought All ON has long been removed from the protocol. No buttons were pushed, it happened due to my sunset program that has run unaltered for years. Didn't bother logging in to check the logs, yet. Curious to see what happens tonight. Nobody here can know with 100% certainty (IF) a newly purchased Insteon product has removed the ALL ON / ALL OFF command set until you test for it. Keeping in mind if you purchase NOS or from a 3rd party vendor you never know. As the product is *New to you* but certainly isn't new in terms of being the latest production units with the latest firmware / hardware.
paulbates Posted June 9, 2016 Posted June 9, 2016 There are 2 parts the all on: A source of the ALL on cmd, and devices that can respond to it. The PLM is a device that had the capability of sending an a all, and that reportedly has been removed from newer PLMs. However, there is speculation that the All-on is a single symptom with multiple root causes. You can have a new PLM with the all command removed, but still in the equation are older insteon devices in your house that detect and react to what they believe is an All-on command. Paul
stusviews Posted June 10, 2016 Posted June 10, 2016 I've experienced a few FEW ON events. like one garage door opening, but not the other or only a couple of lights turning on. Last night was the most unusual. At about 4:30AM, I wandered to the front of the house to check on a computer I was setting up (OK, I do things like that.) when I noticed that the media room torch lamp came on, but nothing else in the media room did. I dutifully turned it off and returned to the bedroom where and entirely different torch lamp was lit. Nothing else in the house was affected. The media room and bedroom are not just on different circuits, they're on different meters. RF is definitely involved.
Bumbershoot Posted June 12, 2016 Posted June 12, 2016 I've experienced a few FEW ON events. like one garage door opening, but not the other or only a couple of lights turning on. Last night was the most unusual. At about 4:30AM, I wandered to the front of the house to check on a computer I was setting up (OK, I do things like that.) when I noticed that the media room torch lamp came on, but nothing else in the media room did. I dutifully turned it off and returned to the bedroom where and entirely different torch lamp was lit. Nothing else in the house was affected. The media room and bedroom are not just on different circuits, they're on different meters. RF is definitely involved. I've experienced a couple of similar events, but the only devices that are turned on are 2477s SwitchLink On/Off switches (v.43) and Insteon LED bulbs (v.47 and v.48). Nothing else that I'm aware of, and no trace of the 'on' event in the logs. Edit: I have no idea if this is related, but when I just queried a Z-Wave deadbolt (Schlage powered door lock), and this error appeared (screenshot) for one of Insteon LED bulbs that was involved in the above 'on' event. The LED bulb seems to otherwise operate normally. UDI firmware and UI are both 5.0.4.
Michel Kohanim Posted June 13, 2016 Posted June 13, 2016 Hi Bumbershoot, Unfortunately not related. Have you tried following the instructions here? http://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events With kind regards, Michel
Bumbershoot Posted June 15, 2016 Posted June 15, 2016 Hi Bumbershoot, Unfortunately not related. Have you tried following the instructions here? http://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events With kind regards, Michel Thanks, Michel. I'm going through my programs now. Nothing unusual regarding my motion detectors in the logs. Bumbershoot
Recommended Posts
Archived
This topic is now archived and is closed to further replies.