Insteon Plug-ins for ISY-26/99i and SmartLinc (with X10)

[techoguy]

Hi techoguy,
Thank you, Ive been testing it and is not perfect as you said, it reduces a bit the collision. how my computer have impact on the plugin's performance? I have a brand new mini pc 24/7.

Hi Karlik,
What are you trying to do where you see the errors a lot? What device and sequence are you seeing or testing?

The computers speed will have a huge impact on the accuracy. Basically the computer has to receive and process the command before another command comes through, if the processing of the command takes longer than the time before the next message received then it will most likely miss the next two messages (it will grab the two messages as one).

The other problem is that if you receive an insteon message and that message triggers an event to send an insteon message right away, this will usually cause an error. So it might help to put a small delay in your event before sending the insteon message. The plugin tries to help with this but it's a timing thing and can be dependent on the computer.

[karlik]

Hi Karlik,
What are you trying to do where you see the errors a lot? What device and sequence are you seeing or testing?

The computers speed will have a huge impact on the accuracy. Basically the computer has to receive and process the command before another command comes through, if the processing of the command takes longer than the time before the next message received then it will most likely miss the next two messages (it will grab the two messages as one).

The other problem is that if you receive an insteon message and that message triggers an event to send an insteon message right away, this will usually cause an error. So it might help to put a small delay in your event before sending the insteon message. The plugin tries to help with this but it's a timing thing and can be dependent on the computer.

Hi techoguy,
What I test for now is: two sensors detecting movement at a time and triggering a scene while a movement is detected. Im using a brand new pc with Intel 2.90GHz and 4G of RAM which is enough to run EG and the plugin. my initial goal is to be able to have my sensors turn on a lamp at different intensity based on the time and to be able to trigger a scene while receiving sensor commands with reliability. I thing in general I want to accomplish receiving and transmitting more than one command at a time. Do you think this "collision" can be solved? is there a way to make this plugin reliable so it can receive and send commands with reliability? my wife is not happy when the light does not go on and I believe insteon it self is powerful enough to handle this situations.

[techoguy]

Hi Karlik,
Based on what i'm reading, it sounds like what you are probably incountering is that the EG is receiving the motion message, but then when EG tries to send the scene command it's failing. This is where a small delay in the action before sending the scene command can be helpful. The Insteon PLM can reject a command from EG if it's not ready (this is known because the PLM will respond with a x15). The plugin I sent you will try to resend the command if this happens but it's not full proof. In my case it's worked well. I get an error once every couple of weeks and i'm doing what you are doing with motion triggering a scene in EG.

If you can cause the error and paste your log here, i will be able to say for sure what is going on and better suggest a solution to make it work more reliably using the current plugin.

You also have to make sure you are triggering off the right message received (there are 2-3 that are received from the motion sensor) If you do not, there is a good chance that EG doesn't even see the message all the time (part of the insteon protocol, not the plugin's fault). When the motion is triggered, a broadcast message is sent from the motion sensor, then clean up messages are sent (if the network is not interrupted by something else on the insteon network). The PLM then also sends responses over the insteon network which are also seen in the EG log.

The collision problem can be solved, and that's why i plan on writing a new plugin. I also hope to make the plugin in filter out many of the messages currently seen so it's easier to use and setup. I just haven't gotten around to doing it yet.

[karlik]

Hi Karlik,
Based on what i'm reading, it sounds like what you are probably incountering is that the EG is receiving the motion message, but then when EG tries to send the scene command it's failing. This is where a small delay in the action before sending the scene command can be helpful. The Insteon PLM can reject a command from EG if it's not ready (this is known because the PLM will respond with a x15). The plugin I sent you will try to resend the command if this happens but it's not full proof. In my case it's worked well. I get an error once every couple of weeks and i'm doing what you are doing with motion triggering a scene in EG.

If you can cause the error and paste your log here, i will be able to say for sure what is going on and better suggest a solution to make it work more reliably using the current plugin.

You also have to make sure you are triggering off the right message received (there are 2-3 that are received from the motion sensor) If you do not, there is a good chance that EG doesn't even see the message all the time (part of the insteon protocol, not the plugin's fault). When the motion is triggered, a broadcast message is sent from the motion sensor, then clean up messages are sent (if the network is not interrupted by something else on the insteon network). The PLM then also sends responses over the insteon network which are also seen in the EG log.

The collision problem can be solved, and that's why i plan on writing a new plugin. I also hope to make the plugin in filter out many of the messages currently seen so it's easier to use and setup. I just haven't gotten around to doing it yet.

Hi techoguy,
In fact my problem is that the plugin doesnt receive all commands, e.g. when two sensors detect movement then one of them wont be received, or when I trigger a scene and a sensor detects movement in that moment then the sensor command is missed (this is the collision problem). I have seen this checking the log, that said, if there is no event then no action will be triggered. I managed a delay as you mentioned couple of days ago, so to transmit the action based on the event is not a "big deal" now. I think the priority is to have the plugin capturing all incoming messages from sensors (or other insteon devices) no matter if the PLM is busy at the moment or more than one insteon device broadcast at the same time. Will this in somehow simplify the plugin modification? can be done the receiving part separated from the transmitting part? I can support as my knowledge allows

[techoguy]

Hi Karlik,
Can you copy your log out put when this occurs or take a screen shot and post it here? (copying the text is usually easier to capture all output needed). Make sure the "verbose mode" is checked in the plugin settings window before capture the log output. Also, can you note where motion occurred if the log doesn't show the insteon message from the motion sensor?
Based on what you are saying, i believe there are two things that could be happening but i can't say for sure unless i see your log. But in general you shouldn't be having that many issues.

Also, do you have two motion sensors in the same room? I'm curious why they would be triggering at the same time. Seeing the log at this point will be the most helpful though. When the motion sensor sees motion it sends around 3 unique messages. The last 1-2 can be canceled per the insteon protocol if another device on the insteon network tries to send a message before all the messages have been sent. So if you're triggering off one of these later events, the event won't show up. In this case, you have to make sure you're triggering off the first broadcast message in EG. The downside to this is if the insteon PLM is far away from these motion sensors there is a chance the 1st message is also missed if the broadcast message doesn't even reach the PLM (insteon has a max hop of 3).

[karlik]

Hi Karlik,
Can you copy your log out put when this occurs or take a screen shot and post it here? (copying the text is usually easier to capture all output needed). Make sure the "verbose mode" is checked in the plugin settings window before capture the log output. Also, can you note where motion occurred if the log doesn't show the insteon message from the motion sensor?

Hi Techoguy, I was away for a while..
I apreciate your help. In the out put below, the log captured only one sensor messages. Two sensors detected movement at the same time "Hall and bathroom".

14:27:18 Received: 025021CF0D000001CB1101
14:27:18 Message from Motion_Hall to unknown device: 01, On.
14:27:18 SmartLinc.Switch.Motion_Hall.On.1
14:27:18 Received: 025021CF0D000001CB1101
14:27:18 Duplicate Mesage: 025021CF0D000001CB1101, ignoring message
14:27:19 Received: 025021CF0D1EB8B2461101
14:27:19 Message from device: Motion_Hall to Hub: On
14:27:19 SmartLinc.Motion_Hall.On.1 u"01"
14:27:19 Received: 025021CF0D110201CB0600
14:27:19 Message from Motion_Hall to unknown device: unknown scene, 06.
14:27:19 SmartLinc.Switch.Motion_Hall.06.1
14:27:19 Received: 025021CF0D110201C70600
14:27:19 Message from Motion_Hall to unknown device: unknown scene, 06.
14:27:19 SmartLinc.Switch.Motion_Hall.06.1

Based on what you are saying, i believe there are two things that could be happening but i can't say for sure unless i see your log. But in general you shouldn't be having that many issues.

The plugin is behaving as you have been describing. if the difference of time between two insteon devices is around one sec, then I dont see really problem.

Also, do you have two motion sensors in the same room? I'm curious why they would be triggering at the same time. Seeing the log at this point will be the most helpful though.

Normally this dont have problem but happens when you really need it, specially when you come in between the sensors detection area quickly and need to go to the side which sensor was not detected .

The downside to this is if the insteon PLM is far away from these motion sensors there is a chance the 1st message is also missed if the broadcast message doesn't even reach the PLM (insteon has a max hop of 3).

Far away? what do you mean? I have those sensors linked modules at 70m cca from the PLM and in the same phase as the PLM. is this far away?. Does it mean that even if a new plugin version manage to detect two insteon device commands at a time, Could still be a problem if they are "far away"?

Having EG to send and receive insteon commands in a reliable way will expand the possibilities.

[techoguy]

Hi Karlik,

The plugin is behaving as you have been describing. if the difference of time between two insteon devices is around one sec, then I dont see really problem.

The plugin only has an issue if the messages received are within 200ms or so. 1 second is too long.

Based on your output, it looks like the motion sensor isn't even seen on the insteon network at the PLM. So this means it's not a plugin issue. Just so you know, every message the PLM receives shows up in the plugin as "Received: 025021CF0D000001CB1101" or similar (lengths can change). This part of the plugin works just fine and sees everything the PLM sees. It's the processing and decoding of these messages that fails or have issues at times. It appears you're having an insteon network issue because the motion sensor's messages aren't reaching the PLM based on what i see.

Just incase you weren't aware, the insteon motion sensors do not send messages every time motion is seen. The way they work is that they will send a motion detected message when motion is first seen. Then a timer starts and there will be no motion messages sent even if the little red LED flashes from more motion. The motion detector will then send a "no motion" message when the timer has expired (this time is adjustable). After this, a motion message will be sent again when motion is seen again.

So you'll see something like this:

Code: Select all

14:27:18 Received: 025021CF0D000001CB1101
14:27:18 Message from Motion_Hall to unknown device: 01, On.
14:27:18 SmartLinc.Switch.Motion_Hall.On.1

then when there has been no motion for the set time you'll see this:

Code: Select all

14:29:18 Received: 025021CF0D000001CB1301
14:29:18 Message from Motion_Hall to unknown device: 01, Off.
14:29:18 SmartLinc.Switch.Motion_Hall.Off.1

before the second message is ever seen, you'll never see a "Motion_Hall.On"
This is also assuming you have not changed the motion sensor to only send on commands (which can be done). If you have changes the motions sensor settings to only send on commands, you'll never see the "off" commands.

Could this be what is happening?
Two questions:
How are the lights turning off if EG is turning them on? Do you turn them off or does EG after a certain time?
is your PLM the Insteon Hub?

As for the distance, i'm not sure if i understand 70m cca? if that's 70 meters between the motion sensor and the receiving module that then forwards the message to the PLM then that could very well be too far.

[karlik]

The plugin only has an issue if the messages received are within 200ms or so. 1 second is too long.

Hi techoguy, you are right. It can be shorter than 1 second, it was my appreciation.

Based on your output, it looks like the motion sensor isn't even seen on the insteon network at the PLM.

in the log output I sent you it looks like is not seen at all by the Hub. however that was a log output of the worst case when one of the sensors is not seeing at all in the first detection (probably because both sensors detected within 200ms or less of difference), when the difference of detection time between both sensors is longer (or coming in to the detection area at slow pace) then I normally dont have issues. my tests are done when the sensors detect movement for the first time, Im aware of the fact that sensors only send On command in the first detection and Off command when the timer expires unless is modified in HL.

How are the lights turning off if EG is turning them on? Do you turn them off or does EG after a certain time?

The sensor turns off the light after the time expires. I would like to modify the sensor settings to enable the presence detection (to send On command every time a movement is detected) and get some open/close sensors and thermostats when the plugin reception would be more reliable.

is your PLM the Insteon Hub?

The insteon Hub

As for the distance, i'm not sure if i understand 70m cca? if that's 70 meters between the motion sensor and the receiving module that then forwards the message to the PLM then that could very well be too far.

The sensor and receiving module are 3 meters from each other, the receiving module is around 70 meters away from the Hub (this is my estimation of the phase wire length between the receiving module and the Hub. in straight line they could be around 20-30 meters away with 4 walls in between) and in the same phase. what is far? I could have insteon devices further than 70 meters

I really see the plugin behaving as you mention, I just imaging expanding and improving the functionality of the insteon network when the plugin reception/transmission is reliable, right now I think I will miss insteon commands in the EG log if the insteon activity increases. based on what Ive checked in the forum, EG has a huge potential that in this case is limited by the smartlinc plugin functionality.

[techoguy]

Hi Karlik,

Based on the log out put you posted, the problem is on the insteon network, not with EG or the plugin (unless there were other messages that weren't copied to the forum).

It is very odd that none of the 3-5 messages sent from the second motion sensor were seen by the PLM (this is why i thought maybe the motion sensor wasn't even sending the "on" message). The plugin wouldn't miss all 3-5 messages.

EG and the plugin have no problem receiving all messages from the PLM, it only has issues processing them. So all messages can be seen similar to "Received: 025021CF0D000001CB1101". The problem is when two messages are too close together and processing the first message takes too long. You'll still see something like this:
"Received: 025021CF0D000001CB11010250XXXXXX00001CB1101. This is where the plugin will fail and miss both of these messages but you'll still see this "Received:" message in the log output with the verbose mode checked.

Just as an example, my own house has 8 motion sensors ( a few of them very close together) and i'm sending insteon messages based on insteon messages received EG with very little problems. I never have a problem receiving the messages. The problem is when EG sends a message on top of another message getting received.

Feel free to send another log output if there is more data received otherwise i would test and play around with the motion sensors more to get them to work more reliably.

[karlik]

Hi techoguy,
I made a clean installation and triggered messages from one motion sensor and one open/close sensor that I recently got. the test is done by pressing the pulse button of both devices at once and I see the plugin receiving messages from both sensors. I run this test several times with same result.
I cant say exactly why I missed commands from one of the sensors in my previous tests (I must check if the sensor is faulty). I will redo everything from the scratch and I hope this wont happen again.


Im now checking if sensor messages are received while insteon scene is sent from EG (scene controlling 6 insteon modules and sensor close to the Hub). the result is as follows:

1. if the sensor send with more than "200ms" before EG fires the insteon scene, then both succeed.

2. if the sensor send with less than "200ms" before EG fires the insteon scene, then the sent scene succeed and the sensor commands "I guess" are received together so the plugin fails to process them 13:41:25 Received: 025014C521000001CB1301025014C5211EB8B2411301025014C521130101CB0600.

3. if the sensor send at the same time EG fires the insteon scene or up to about "500ms" after the scene is fired (my guess is that this time depend on the number of insteon devices contained in the scene). the sensor commands are not seen at all but the scene succeed.

When I run the same test with a single Device On command fired from EG, then the time window when no command sensor is received (3) is highly reduced.

My conclusion is that all fired commands from EG succeed and the received commands wont show up in the log processed if too close before the other is sent or will not show up at all if both are fired at the same time up to the time the transmission of the sent command finished. the next problem to solve would be to send more than one command at once but I dont see this as a major issue for now


I think this is the problem you describe and probably this is what I experienced initially therefore only one sensor succeeded. Also, this problem doesnt allow me to walk into sensor detection areas while I trigger a scene from my basic html, I would need to think where I or someone else is moving and when I can trigger. besides the reliability problems when a person is moving into a sensor detection area, a door is being opened, a thermostat send the new room temp value.. etc while a scene is triggered automatically by EG due to a change in conditionals. Is possible for you to help me modifying the plugin to avoid the collision so the experience is improved? at least for now the reception while EG fires insteon messages.

I thank you for all your patience and help.

[techoguy]

Hi Karlik,
That is exactly the problem the plugin has. When you send a scene command from the Hub using EG, it sends a broadcast message. Then the hub will send a clean up message to every device within the scene which is also captured within EG. So the more devices the more messages are sent (this is the Insteon protocol not the plugin).

Currently there isn't too much I can do to the current plugin. This is why I have planned on re-writing it so it can properly process all commands. Normally I don't have that many issues but i'm not trying to trigger large scenes based on other insteon devices. I have made some modifications to make it better but it's just not good enough and with your setup, i'm not sure it would ever be unless it was rewritten.

My hope is to write a new plugin soon, but i just can't guarantee a specific time frame.
I will let you know as soon as it's completed so you can test it in your setup.

[karlik]

My hope is to write a new plugin soon, but i just can't guarantee a specific time frame.
I will let you know as soon as it's completed so you can test it in your setup.

Thank you techoguy,

[barnabas1969]

It's been a long time since I studied the Insteon protocol, but I seem to remember that the message length is in the message somewhere, and there are some starting bits too. Couldn't the plugin be written to loop on each message when it receives what appears to be a bunch of messages appended together?

[techoguy]

It's been a long time since I studied the Insteon protocol, but I seem to remember that the message length is in the message somewhere, and there are some starting bits too. Couldn't the plugin be written to loop on each message when it receives what appears to be a bunch of messages appended together?

Hi Barnabas1969,
You are correct. Every message starts with an 02 and the next two digits represent the message type. In most cases the message type is a certain length (not included in the message itself) but there are some message types that have multiple lengths depending on other data in the message. The down side to this method is that there are cases where a start bit (02) and a message type pattern can be created somewhere else in the message so simply looking for the start bit isn't good enough.

I've started writing a matrix that links these lengths and message types based on the documents. The plan for the new plugin will basically just loop through all bytes to separate messages and process all of them as you mention. The main reason a lot of the plugin will have to be rewritten is that currently the messages are processed by their length only instead of the message type. The other issue right now is that the plugin doesn't differentiate scenes from the hub and other devices. It was written as though the hub is the only device that can broadcast scenes. This currently causes errors if you have a scene in the hub that is defined in EG and another device broadcasts the same scene number. It needs to be written so that every device has it's own scenes. I plan on creating a setup window that allows you to define the scene for a device when you add it. For example, the motion sensor has a few scenes so you will be able to program it such that scene 1 is the normal motion, scene 2 is the dusk/down scene, 3 is the battery low scene (this is only an example, can't remember off the top of my head if those are the actual scenes from the motion sensor). In the case of a keypad, you'll be able to assign names to all the buttons which broadcast scenes 1-8.

the insteon protocol is not very robust so it makes it a pain to write a plugin/api for it that is reliable.

[davidmark]

I downloaded what I assume is the latest "Insteon Smartlinc" plugin from this thread, but it seems to be broken. "Bad File Descriptor" on second and subsequent sends. Restarting makes it work one more time. Granted, this may be an issue with Houselinc running on the same network as I think there can only be one socket connection at a time. Never saw any incoming signals (Insteon or X10), whereas Houselinc logs everything (though it isn't very good at interpreting the data). Can't remember if Houselinc was running at the time of testing, but if the plugin could send a command (which it could do once per restart), it should be able to listen to the socket as well.

Have you considered using the 25105 port to send HTTP commands? Works like a charm. Granted, would still have to grapple with the socket connection for listening.

Also, the X10 commands make no sense to me, nor does the comment about changing the house code from a hard-wired "B" (line numbers referenced are clearly incorrect). When I choose an action to turn on an X10 device, I get a dropdown with nothing but Insteon devices (addressed XXXXXX, not A1, A2, etc.) Can't this thing send, for example, A1 AON? That would be a start.