"All on" glitch

maxnorth · December 28, 2015

Twice now, my ISY994i has turned on all my devices at once, randomly. This includes opening my garage door, which is a real security concern. It happened today and once maybe six weeks ago.

I do not have an "all on" program or scene anywhere.

I pulled the error log and there are no errors logged for today.

There was nothing in particular going on at the time.

I also notice that it turned them on, but my normal timer programs designed to turn things off did not run. I manually turned everything off. Other than the glitch with the timers, the ISY appears to be functioning normally now (without me rebooting it).

All of this suggests a glitch with the ISY, including a freeze of some sort that preventing my timers from being triggered.

Suggestions for diagnosis? I've got an Elk, Mobilinc and the Z-Wave module, but no network module. Static IP, 4.3.26 and 1755 MB free.

Teken · December 28, 2015

http://forum.universal-devices.com/topic/10516-random-all-on-event/

larryllix · December 28, 2015

Q?

Do you have Insteon motion detectors?

MWareman · December 29, 2015

I always advise to never hook a garage door opener to an iolinc. Insteon does not contain the needed security protections.

maxnorth · December 29, 2015

Thanks all. Teken, I went through the master "all on" string you linked to (funny that my "all on" search did not bring that up initially). I must say, 36 pages of posts is not a very efficient method of troubleshooting. Too bad UDI can't simply summarize the issue and keep the summary current. It's pretty essential to separate fact from speculation with a problem like this.

I'll have to watch this to see if it gets worse and will consider updating my PLM (I'm at V9B still).

I have also introduced some wait times into my scenes where possible, especially those updating LEDs. I do have multiple motion sensors.

I am considering removing the IO Linc on my garage door opener, although I already have it set to notify me whenever it opens, so I can always close it remotely should the need arise.

MWareman · December 29, 2015

Too bad UDI can't simply summarize the issue and keep the summary current.

They have. See http://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events

Michael.

Teken · December 29, 2015

Thanks all. Teken, I went through the master "all on" string you linked to (funny that my "all on" search did not bring that up initially). I must say, 36 pages of posts is not a very efficient method of troubleshooting. Too bad UDI can't simply summarize the issue and keep the summary current. It's pretty essential to separate fact from speculation with a problem like this.

I'll have to watch this to see if it gets worse and will consider updating my PLM (I'm at V9B still).

I have also introduced some wait times into my scenes where possible, especially those updating LEDs. I do have multiple motion sensors.

I am considering removing the IO Linc on my garage door opener, although I already have it set to notify me whenever it opens, so I can always close it remotely should the need arise.

Yeah, the search doesn't bring up that specific thread unless you know the key phrase. Apologies you had to wade through all 36 pages for information but its best you read whats going on and what some of the possible interim fix's are. I am of the opinion most of these fix's are just band aids to a underlying issue.

There isn't a soul that can explain why and how a person can walk around their home all day long and nothing happens for months. Yet in the same breath the majority of people will also be dead asleep or out of the house and come back to see the entire home all lit up?!?!

Any reasonable person would call bull sh^t that (added) wait times are going to solve the issue at hand. There are several people who also have no motion sensors, replaced the PLM with the latest and greatest yet this issue still appears.

The fact it still happens indicates there are other factors not being considered . . .

At the end of the day there isn't one single person who can reproduce the ALL ON / ALL OFF issue at will and let others do the very same.

I find that incredible, and hard to believe at the same time, but apparently its true. The biggest problem is there are too many moving parts in this whole issue. Many people have various model years, firmware, and programs in place. While others have hardware that are known to default to a on state when their is a power loss.

There was a thread not too long ago where a fellow almost burned down his house because his daughter dropped her scarf on a lamp and when she was out and about the power blipped. When the power came back on that switch resumed in a on state.

So, people have to take that into consideration in knowing do they have such hardware in place? Was the actual ALL ON caused by bad firmware in the switches? Now it doesn't explain the I/O Linc but then again who knows if certain years also had odd behavior programmed in their firmware.

Knowing Smartlabs its not a stretch they had bad firmware in place and have since corrected some of them. People could say *Teken, how the hell do you know that* well because today's I/O Linc has a different hardware revision number along with different firmware listed in the ISY.

They didn't change that because it was fun . . .

It was changed because they decided or found out a specific scenario would cause XYZ to happen. As of this writing Smartlabs is in the midst of removing the ALL ON / ALL OFF command tables from all shipping products. Nobody really knows if this project is completed or where it is in the pipe line. Considering there are lots of NOS gear in the market place from various on line sellers etc.

Ultimately, what will prove very interesting is to see an entire home void of any hardware that has native ALL ON / ALL OFF commands inside along with the same 2413S PLM and if the this issue is still present.

If it happens in this scenario well you pretty much know where its coming from . . .

maxnorth · December 29, 2015

Thanks, Michael. I thought the wiki had become stale, so I don't normally check there. My bad. I don't use "control" in my programs, so that is really not a helpful summary (or likely correct).

Teken, I share your extreme frustration. It does not seem to make sense, and it feels like we are missing something. In the meantime, I'm simply going to have to create some monitoring programs and rely on my remote capabilities to shut things down if this happens while I'm not at home. (or perhaps shut them down automatically if I can detect the event reliably.)

I get that the "all on" event is supposedly not "sent" by the ISY, but has anyone explained why the ISY does not detect the status of the devices that are turned on by the event? Does that not suggest that the problem lies with the ISY?

Xathros · December 29, 2015

Thanks, Michael. I thought the wiki had become stale, so I don't normally check there. My bad. I don't use "control" in my programs, so that is really not a helpful summary (or likely correct).

Teken, I share your extreme frustration. It does not seem to make sense, and it feels like we are missing something. In the meantime, I'm simply going to have to create some monitoring programs and rely on my remote capabilities to shut things down if this happens while I'm not at home. (or perhaps shut them down automatically if I can detect the event reliably.)

I get that the "all on" event is supposedly not "sent" by the ISY, but has anyone explained why the ISY does not detect the status of the devices that are turned on by the event? Does that not suggest that the problem lies with the ISY?

While I haven't had anymore All-On events, I did build a program to watch for them, notify me and shut things down in the event of another All-On. I used a spare Lamplinc module and plugged it in alongside my phase bridge at the main panel. No load connected and I keep this module Off. I have a program that queries the module once every minute. I have another program that triggers if that module's status changes to "On" and sends a notification and turns off my "Almost Everything" scene with the assumption that if that module turned on, an All-On event has occurred.

Hope this helps.

-Xathros

maxnorth · December 29, 2015

Thanks, Xathros. My plan is to pick 5 or so disparate devices and create a 5 second timer for each (control method). Then create a program that says that if any of those devices goes on (control) while all timers are still active, then consider it to be an All On event.

Teken · December 29, 2015

Thanks, Michael. I thought the wiki had become stale, so I don't normally check there. My bad. I don't use "control" in my programs, so that is really not a helpful summary (or likely correct).

Teken, I share your extreme frustration. It does not seem to make sense, and it feels like we are missing something. In the meantime, I'm simply going to have to create some monitoring programs and rely on my remote capabilities to shut things down if this happens while I'm not at home. (or perhaps shut them down automatically if I can detect the event reliably.)

I get that the "all on" event is supposedly not "sent" by the ISY, but has anyone explained why the ISY does not detect the status of the devices that are turned on by the event? Does that not suggest that the problem lies with the ISY?

I think people really need to sit down and really consider some of the basic elements which most of us believe is grounded in facts. In my experience there are several ways a controller may not be aware of state change.

There may be more but off the top of my head here are the most common ones.

- Device(s) are linked manually outside of the controller.

- Links are lost in the 2413 PLM due to the ever present capacitor issue.

- Noise: Typically when noise makers / signal suckers are present it can cause Insteon signals to be lost in the ether.

- Power: If there is ever a loss of mains power and the PLM is not brought back on line before the ISY there will be out of sync issue.

- ISY Lock Up: Depending upon how many network, programs, etc are active this condition can cause the controller to miss a change in state.

Now the above are known and accepted scenarios where it is outside of the control of the 994 Series Controller. Lets assume none of the above is true and all hardware is operating perfectly fine.

There are user issues that are supposedly at play here that cause these conditions to be more prevalent when compared to others.

- Tight loop programs (repeats, polling, query, active on start up)

- Poorly crafted programs that have direct conflict of other active programs.

- Too many network related applications being executed thus causing a delay or missed status.

So now we have what some believe are collisions of data packets in the Insteon network.

- This could be from battery powered devices because they are known to send out multiple On/Off commands.

- Low battery condition where the MS sends continuous streams of On's when in a low battery state.

Now, the next possible culprit is hardware that has firmware that by default restores a device to a on state when power is lost. Keeping in mind some hardware devices require at least 1-3 seconds of power loss before this happens. Where as others simply need a blip in power and this condition will be seen.

Having said all of the above I want people to sit down and really consider how it is someone can walk around for months, years, and have the exact same set up and never make a change.

Out of no where this problem arises?

Read what I stated and say it aloud does that logic track?!?!

Its not very often I use the word impossible because most of us who have been around long enough knows. Impossible simply takes longer to accomplish. My point being is if your home was a ticking time bomb because you were too stupid to program your controller with clean code, had crappy power, didn't bother changing out batteries, had dozens of network resources running 24.7.365.

Why isn't this problem happening everyday, every hour, every second??

You see how none of that makes any sense? If your home was teetering on imploding because you were completely clueless about basic *Best Practices* this problem would be happening all of the time.

In fact it doesn't and yet dozens of the smartest people on this forum, engineers, and application experts are unable to isolate, reproduce, and repeat any of this in another environment?

Impossible . . .

As I stated above (assume all is well hardware wise) and ignore any possible hardware that is affected with a return to a on state when power is restored. There are dozens of Insteon devices which are linked to a PLM. The controller has direct connection to the PLM and should know when a state change has occurred.

Yet we are to believe none of this is visible to the controller on a massive scale?!?!

Impossible . . .

My view is this isn't visible in the logs because its simply not known and tracked. Its impossible that 1 - 100+ devices which have links in a PLM which the controller manages and has complete command and control over has no clue something on such a massive scale has happen.

Keeping in mind there isn't one controller or software application in the open market that does the very same, none. Smartlabs isn't known for making very reliable and robust controllers yet even their most feeble device has never been documented to see such a condition?!?!

There are dozens of software only applications which also use the 2413S PLM for direct communications and not one of them has ever seen this issue.

Now, on a complete tangent I was told there were model years of Insteon hardware that could issue a ALL ON / ALL OFF command set when failing. I have never seen or heard of such an event that was ever documented here in the forums so don't put too much weight on such a scenario.

I have also never read of a person who could invoke a system wide ALL ON / ALL OFF command using what ever method via software / controller. This last part is important to note because I believe if we fully understand how this command can be invoked at a basic level.

Then, it should not be a stretch to craft software to negate the very same . . .

Xathros · December 29, 2015

Thanks, Xathros. My plan is to pick 5 or so disparate devices and create a 5 second timer for each (control method). Then create a program that says that if any of those devices goes on (control) while all timers are still active, then consider it to be an All On event.

That won't work. Control events are only generated when devices are manually actuated at their paddles. When commanded on by a remote linked scene/device, status changes but no control event is generated. Since devices don't transmit their status changes unless queried, the ISY is unaware of the All-On, thus the need to periodically query a device for an unexpected state change.

-Xathros

Edited December 29, 2015 by Xathros

maxnorth · December 29, 2015

Ah, thank you. Hence the need to poll like in your setup.

maxnorth · December 29, 2015

I agree it seems impossible.

Maybe it's just the NSA testing that backdoor UDI put in the ISY for them

Teken · December 29, 2015

I agree it seems impossible.

Maybe it's just the NSA testing that backdoor UDI put in the ISY for them

LMAO

I know for a fact if there was one company that prides itself in security / privacy that is UDI.

Lastly, I don't want anyone to take my writings the wrong way. UDI has stood fast in helping and facilitating with Smartlabs in obtaining Beta PLM's in hopes of solving this issue.

My point is this is just a band aid to a much larger issue that isn't being explored or reviewed.

As others have mentioned in the past more low level diagnostics needs to be implemented system wide which monitors all traffic and command sets.

It's simply not possible a global all on - all off is issued to the entire network by a malformed data packet due to collision.

Keeping in mind why doesn't a low battery state which is known to send endless on's (without a controller in place) never cause a all on / all off?

Where are people placing a (wait command) in the Insteon network? It certainly isn't being placed natively into any Insteon hardware now is it?

Ignoring hardware that is known to resume on upon power failure. Even if you had the crappiest power known to man why doesn't it happen every time there is a power blip?!?

Lastly, there are several users who have replaced the PLM yet this problem is still present.

Really?!?

It's impossible a device which has no command set to do so has this capability. Why is this important to note?

Because people are saying some random message caused the PLM to issue a global all on / all off.

There is a higher likelihood that I get struck by a pink elephant from the sky then the PLM doing this all by itself all the while the ISY is unaware of this action?

Come on, I wasn't born yesterday!

Ideals are peaceful - History is violent

Xathros · December 29, 2015

My point is this is just a band aid to a much larger issue that isn't being explored or reviewed.

I have to agree. However, until the exact cause is identified, what more can we do?

As others have mentioned in the past more low level diagnostics needs to be implemented system wide which monitors all traffic and command sets.

I still don't understand why SmartLabs has not developed and brought to market a more meaningful/useful diagnostic tool.

It's simply not possible a global all on - all off is issued to the entire network by a malformed data packet due to collision.

Here, I must disagree. I am confident that this is caused by overlapping/colliding insteon messages and I'm not convinced that the PLM is playing ANY role in the All-On in generating the All-Ons

Keeping in mind why doesn't a low battery state which is known to send endless on's (without a controller in place) never cause a all on / all off?

I believe I HAVE seen several All-On's caused by the low battery chatter of one of my older MS units.

Where are people placing a (wait command) in the Insteon network? It certainly isn't being placed natively into any Insteon hardware now is it?

Waits are paced in ISY programs to separate triggering device traffic from traffic caused by the triggered program in an effort to prevent overlapping messages. I believe this is really only important when the triggering devices are battery powered devices that can't monitor the line for traffic before transmitting.

Lastly, there are several users who have replaced the PLM yet this problem is still present.

As I mentioned above, I'm not convinced that the PLM even matters. I also suspect that the reason I haven't had any more All-On's isn't due to replacing the PLM but rather the fact that I removed ALL of my Triggerlinc door sensors and replaced them with hard wired switches through a Pi. I'm in the process of sourcing hardwired PIR's to replace my Insteon MS's in the same way. The problem does appear to get worse as more DualBand devices are added to the network which makes me suspect multi-path communications plays a significant role.

One question that keeps surfacing on this topic is: Why do only ISY users see All-On's? I think it's because the ISY is one of the only controllers that allows for complex programs issuing Insteon Direct commands rather than just scene commands. This results in different traffic patterns than are seen with the "Other" controllers. This however is just a guess/gut feeling on my part. Having not used the "Other" controllers, I'm don't feel qualified to state that with any certainty.

Hi Teken-

I feel your frustration and that of others still suffering from these events. My thoughts and comments in Blue above.

-Xathros

Edited December 29, 2015 by Xathros

mwester · December 29, 2015

So what is unique about the "all on" command that makes it the ONLY one that EVER gets "auto-created" by RF message collisions?

As Xathros says, what more can we (user community) do? Not much, I fear -- other than keep the involved vendors' collective feet to the fire. There is something unique about the ISY/PLM combination that does this, and I have to say that I'm disappointed in the response, which seems to be utter and total silence by SmartHome and "We don't know what else to do and we think it's SmartHome's problem" from UDI.

There IS lots more that can be done. I've said it before - here it is again -- start with something simple, a cheap device (arduino based) that functions as a data logger on the serial port between the ISY and the PLM, logging every character it sees coming and going with timestamps and sequence numbers. A simple I/O Linc device will serve to detect the "All On", which the logging device should treat as the signal to write the last 10 minutes (or whatever) of data logged in memory to an SD card. I'm suggesting this because it's cheaper to send a bunch of these out to those plagued by "All On" events than it is to send a full-fledged logic analyzer with operator to each site.

Once this data is collected, we can then use it to confirm some facts:

a) Does the ISY, in fact, generate an "all on" message and send it on the serial port?

Does the "all on" message occur only when certain other messages are sent (i.e. correlation)?

c) Is there any message coming FROM the PLM that might alert the ISY that this event has happened (i.e. possibility for correction)?

Another possibility is to change out the PLM from serial to USB -- perhaps this problem is avoided on SmartHome's USB PLMs. In order to test, again one can use a simple outboard device -- the device (perhaps a Raspberry Pi) needs to connect to the PLM (easy, just plug it in), and to the ISY (needs a USB->serial converter, but that's not too hard to find). A program simply copies the bits from one port to the other - really, really basic stuff. I suspect unless a firmware mod is made on the ISY, the program would have to fake out the identifier from the PLM if the USB PLM identifies itself differently than the serial one... again, can't be too hard.

(hmmm.... I think my serial PLM is failing, I've some comms errors and it's at the 2 year mark... I have a USB PLM in a box, and I have a raspberry pi on the bench, and I have a USB/Serial adapter, and I have some connectors, wire, and a soldering iron... perhaps a New Years day project to see if I can make this work... )

Teken · December 29, 2015

So what is unique about the "all on" command that makes it the ONLY one that EVER gets "auto-created" by RF message collisions?

As Xathros says, what more can we (user community) do? Not much, I fear -- other than keep the involved vendors' collective feet to the fire. There is something unique about the ISY/PLM combination that does this, and I have to say that I'm disappointed in the response, which seems to be utter and total silence by SmartHome and "We don't know what else to do and we think it's SmartHome's problem" from UDI.

There IS lots more that can be done. I've said it before - here it is again -- start with something simple, a cheap device (arduino based) that functions as a data logger on the serial port between the ISY and the PLM, logging every character it sees coming and going with timestamps and sequence numbers. A simple I/O Linc device will serve to detect the "All On", which the logging device should treat as the signal to write the last 10 minutes (or whatever) of data logged in memory to an SD card. I'm suggesting this because it's cheaper to send a bunch of these out to those plagued by "All On" events than it is to send a full-fledged logic analyzer with operator to each site.

Once this data is collected, we can then use it to confirm some facts:

a) Does the ISY, in fact, generate an "all on" message and send it on the serial port?

Does the "all on" message occur only when certain other messages are sent (i.e. correlation)?

c) Is there any message coming FROM the PLM that might alert the ISY that this event has happened (i.e. possibility for correction)?

Another possibility is to change out the PLM from serial to USB -- perhaps this problem is avoided on SmartHome's USB PLMs. In order to test, again one can use a simple outboard device -- the device (perhaps a Raspberry Pi) needs to connect to the PLM (easy, just plug it in), and to the ISY (needs a USB->serial converter, but that's not too hard to find). A program simply copies the bits from one port to the other - really, really basic stuff. I suspect unless a firmware mod is made on the ISY, the program would have to fake out the identifier from the PLM if the USB PLM identifies itself differently than the serial one... again, can't be too hard.

(hmmm.... I think my serial PLM is failing, I've some comms errors and it's at the 2 year mark... I have a USB PLM in a box, and I have a raspberry pi on the bench, and I have a USB/Serial adapter, and I have some connectors, wire, and a soldering iron... perhaps a New Years day project to see if I can make this work... )

Hello Mwester,

I was wondering when you would chime into this topic.

Ha . . .

Back on topic: I have to agree a bridge device should be used to log all inbound / outbound data packets. As Xathros indicated he doesn't believe the PLM has any real impact on this whole issue and I and many other agree completely.

I can tell you from personal experience what my observations are with respect to what's going on. First, this is a waiting game in terms of how many people are impacted and documenting those numbers. Next, its reducing their liability and risk moving forward because Smartlabs has initiated a product wide removal of the ALL ON / ALL OFF command set.

This was done to the 2413S PLM because in the early days people were under the belief this was the root cause. Well time and history has proven the 2413S PLM is not root cause or solution because if it was those using them would not be seeing this persistent issue would they?

Next, Smartlabs figured we better get a handle on this moving forward and removed the ALL ON / ALL OFF command set to all current shipping products.

Again, this was done to reduce liability and future risks . . .

It does not help or resolve those millions of installations which have native ALL ON / ALL OFF command sets written into their hardware (firmware) set. So next people are saying random RF Insteon based signals from battery operated devices are one of the main drivers and the primary culprit has been the Insteon Motion Sensor (MS).

I would probably accept and believe this to be true but given the dozens of stories in this forum and others where not a soul was present or awake when a ALL ON / ALL OFF event occurred the facts don't track.

Then we have lazy, inept, programming to blame . . .

I freely concede, I fall into this category of lazy, inept, and unaware of dirty coding as its apparent 40 plus people are too!

Because what people are trying to sell me and others (which I won't buy) is that bad coding in the system is the another factor in causing this issue to arise!?!?!

As indicated above this so called ticking time bomb of bad / dirty coding is going to resolve itself by adding wait periods and so forth.

Lets all sit down and track what I just wrote for a minute shall we.

I have every possible condition that is a cesspool to generate this terrible situation. Yet I can walk around naked all day long for days, weeks, months, years, having the above things in place. Yet it won't happen every second, minute, hour, day, week, month, year?!?!

Does anyone smell what's brewing, what does the Rock say when such conditions exist? Again, lets even dumb this down to its basics and fully understand what is being said and not said.

If I have a Insteon network void of any sort of controller in my home there hasn't been a documented case here or other that has experienced a ALL ON / ALL OFF condition, ever . . .

I mean ever . . .

So we have tens of millions of homes with no controller at all and not a soul has ever experienced this condition. Its safe to say based on time and history its not from RF battery operated devices causing the same.

That is a plain simple fact and not conjecture at this point in time.

Ultimately as I stated above with the advent of removal of the ALL ON / ALL OFF command set from shipping hardware everyone is simply buying time and waiting for the dust to settle. I've been following this condition since day one and over the years its incredible that this issue hasn't been laid to bed.

This issue is distracting, and harmful to UDI and the 994 Series Controller. Every month I receive at least one personal e-mail asking me what can be done and my thoughts. I've abstained from offering anymore insight that hasn't already been posted in the public domain.

As its not something I have direct control over or insight too on a personal level. Having said all of this, its my belief more can be done as Mwester has indicated above.

As stated in the ALL ON thread there are several things that can be initiated and started to identify root cause.

1. Take a user who is impacted by this problem and swap out all existing devices with new hardware which is void of ALL ON command sets. This user is the epitome as a controlled subject because we know 100% the hardware is not capable of accepting these bad comms.

2. Next we take another user and remove the controller from the environment for a specific duration leaving everything else in place.

3. Last, we take another user and review all programs, links, scenes, etc. In this case we do nothing except track the frequency of the events via data logging.

Of course all three test cases would have a bridge to monitor all inbound / outbound traffic. All of these examples are doable and quite frankly should have been done two freaking years ago!

In case its not clear this whole situation frustrates the hell out me because something can be done!

larryllix · December 30, 2015

Just to add more fuel to the evidence. Case in point, I have ten active Insteon MS units and have never experienced an All off/on in two years now.

I have experienced massive retries from MS units that get no response and would venture to say, without testing to back this up, that multiple retries don't happen once the MS units are directly linked to a Switch link or other Insteon device that acknowledges the command send out, and no ISY intervention is involved.

My suspicions are that this "signal clash" is a problem with the serial port driver in ISY not handling Xon/Xoff or other control characters in the data stream from the PLM. As I understand it, the serial port is a proper three-wire EIA-232 signal protocol and signals inside of other data packets can be hard to handle without problems. Buffer overrun is usually the result and erroneous data can be sent if not handled correctly at either end.

Edited December 31, 2015 by larryllix

maxnorth · January 7, 2016

As the OP on this string, I thought I'd post an update. I've had no further All On events, but now my PLM is failing. So, consider this a possible additional data point: Is an All On event caused as a PLM is in the process of failing?

It's a 2413S, v9b, V1.B hardware level, 1325. Almost exactly two years old.

What the current read on the PLM? I've seen the cap replacement topic. Better to upgrade the caps, or simply buy a new one with v2 hardware (and new warranty)?

Teken · January 7, 2016

As the OP on this string, I thought I'd post an update. I've had no further All On events, but now my PLM is failing. So, consider this a possible additional data point: Is an All On event caused as a PLM is in the process of failing?

It's a 2413S, v9b, V1.B hardware level, 1325. Almost exactly two years old.

What the current read on the PLM? I've seen the cap replacement topic. Better to upgrade the caps, or simply buy a new one with v2 hardware (and new warranty)?

I believe if cost is an issue and you're mechanically inclined and have all the proper tools than the repair is a good first step. If however you wish to take your chances on another piece of hardware that has another 2 year warranty.

That is a personal financial choice you need to decide on your own.

Keep us in the loop regardless . . .

Brian H · January 7, 2016

Larry.

The IM {Insteon Modem aka PLM} does not use Xon/Xoff or any other control characters. Command echoing. Is used between the ISY Interface and the PLM serial port.

Developers guide explains how it it supposed to work.

I can see problems if each part of the serial exchange does not wait for the proper message echoed back.

http://cache.insteon.com/developer/2413dev-042007-en.pdf

Edited January 7, 2016 by Brian H

larryllix · January 8, 2016

Larry.

The IM {Insteon Modem aka PLM} does not use Xon/Xoff or any other control characters. Command echoing. Is used between the ISY Interface and the PLM serial port.

Developers guide explains how it it supposed to work.

I can see problems if each part of the serial exchange does not wait for the proper message echoed back.

http://cache.insteon.com/developer/2413dev-042007-en.pdf

Thanks Brian.

The handshakes are done with ACK and NAK single characters but at a higher layer of the protocol than Xon and Xoff would be..

I see possible problems with this simple protocol.

There is no confirmation of any commands before action is taken.

A single byte synchronisation code is dangerous and out of message framing errors can occur easily. I see why SH would remove the All On capability from their devices.

The timeout on the message packets is also dangerous for a CPU that can get busy handling other tasks. The next byte coming could be interpreted as a new message command if a 02 is in the data.

With a _{EDIT: re BLH below}~~TTL level~~ 19,200 baud interface down a cable, I am surprised we don't get more messes.

The IM buffers IM Commands as it receives them, so you can send a complete IM

Command without pause. To maintain compatibility with earlier IM versions, the IM

will echo each byte that it receives (earlier versions of the IM used byte echoing for

flow control). You can now ignore the byte echos, but in order to avoid overrunning

the IM’s receive buffer, you must wait for the IM to send its response to your current

IM Command before sending a new one.

Note that there is a maximum time between IM Command bytes that you send to the

IM. If you do not send the next expected byte of an IM Command within 240

milliseconds after sending the previous one, the IM will reset its message parser and

you will have to resend the message from the beginning. You can disable this

Deadman feature by setting a configuration bit (see Set IM Configuration44 below).

There is no flow control when the IM sends data to the host—the IM will transfer data

to the host as fast as it can send it.

Edited January 8, 2016 by larryllix

Brian H · January 8, 2016

The communications between the PLM and the ISY994i is RS232 not TTL.

http://forum.universal-devices.com/topic/17707-isy994i-to-plm-serial-port-ttl-or-rs232/

Edited January 8, 2016 by Brian H

larryllix · January 8, 2016

The communications between the PLM and the ISY994i is RS232 not TTL.

http://forum.universal-devices.com/topic/17707-isy994i-to-plm-serial-port-ttl-or-rs232/

Thanks Brian.

This seems correct. The IM chips talks TTL "Rs-232" other onboard components but the PLM talks RS-232 levels.

The inversion certainly wouldn't make good comm partners.

Sign In

"All on" glitch

Recommended Posts

maxnorth

Teken

larryllix

MWareman

maxnorth

MWareman

Teken

maxnorth

Xathros

maxnorth

Teken

Xathros

maxnorth

maxnorth

Teken

Xathros

mwester

Teken

larryllix

maxnorth

Teken

Brian H

larryllix

Brian H

larryllix

Recently Browsing

Who's Online (See full list)

Forum Statistics

Browse

Activity