EventGhost

techoguy wrote:

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 wrote: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.

techoguy wrote:

davidmark wrote: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.

Hi Davidmark,

The plugin and houselinc cannot be connected to the same smartlinc (PLM) at the same time. There is only one socket to connect to and to receive all messages any program has to stay connected at all times. A way around this is to create a proxy server that allows more than one connection then controls the traffic to the smartlinc. I've thought about adding this feature to the new plugin (not posted yet) but don't have time right now. So, if you use the plugin, houselinc must be shut down completely (sometimes just hitting the x doesn't close the actual connection it has with the smartlinc).

As for the X10 stuff, i did not write the version that you have downloaded and I personally don't have any x10 devices so I can't comment on that.

I will say, i have started writing a new plugin and got about half way and have just not had time to complete it. Basically i got to the point where the plugin can receive and send insteon commands regardless of the timing and it successfully receives all messages and properly decodes them all. I still need to write the interface to all of this and handle the scene messages. I want to get this completed cause i rely on it heavily in my home but I don't know when i'll have time to finish it at this moment.

Also, i'm not sure if i'm familiar with the 25105 port, is this the web gui port that is used for the app?

davidmark wrote: Will try again without the Houselinc, but sounds like I should wait for the new plugin.

As for the HTTP port:

http://blog.automategreen.com/post/unde ... n-hub-hood

http://www.leftovercode.info/smartlinc_x10.html

Works like a charm, just have to find (and optionally change) the username and password in the House settings in the app. The cloud service (if connected) sets these to seemingly random strings (as opposed to "admin" and the Insteon ID that was used previously). Once you have that, you can use basic authentication to send X10 and Insteon commands. ISTM that's the way to go as it won't be affected by socket issues.

Please let me know when you finish the new plugin. Would be glad to test it and offer suggestions. Thanks!

techoguy wrote:

davidmark wrote: Will try again without the Houselinc, but sounds like I should wait for the new plugin.

As for the HTTP port:

http://blog.automategreen.com/post/unde ... n-hub-hood

http://www.leftovercode.info/smartlinc_x10.html

Works like a charm, just have to find (and optionally change) the username and password in the House settings in the app. The cloud service (if connected) sets these to seemingly random strings (as opposed to "admin" and the Insteon ID that was used previously). Once you have that, you can use basic authentication to send X10 and Insteon commands. ISTM that's the way to go as it won't be affected by socket issues.

Please let me know when you finish the new plugin. Would be glad to test it and offer suggestions. Thanks!

Okay, yeah i'm aware of the standard HTML calls. The issue with this method is that you don't get messages from the insteon network and to get status is slow and a little inconsistent. The HTML stuff is good to send commands but that's it. If you have sensors or triggers for when a switch is pressed, you won't receive them using the HTML interface. You would have to pole every device on your network periodically. The other port allows you to see all the traffic on the insteon network which allows us to trigger off insteon events instantaneously. The current plugin does work (I've been using it for over a year now) but the main limitation is that if two insteon messages are sent too close together, they might be missed. This mostly occurs if you have two motion sensors that can be triggered at the same time. it is a limitation but currently it does work. Of course, i don't use it for X10 so I can't really comment how it works for that.

coricidin wrote:I having trouble with devices statuses using this plugin, but only for wired devices such as switchlincs. When I issue the device status command through the plugin for a switchlinc, it always returns the status as "off", regardless of whether the switch is actually off, on, or dim.

It works fine for plugged-in devices such as lamplincs, it returns the status correctly. But with the switchlincs it always returns "off". Any thoughts? I use the hub as my PLM.