Alternate Insteon implementation?

I originally picked up the Vera3 so that I could add some Z-Wave gear to my existing Insteon network. However, the Insteon implementation seems to be about as basic as possible. I can turn on/off lights and dimmers through the UI, but the UI doesn’t show the current state when the switch is toggled at the wall. The keypad linc acts like a simple on/off dimmer switch, with no obvious way to get the other buttons working. (Yes, I have seen the forum posts about how to get it to work, and the numerous replies that indicate it didn’t work for them.) Everything that I have read indicates that my EZflora probably isn’t going to work when I get around to trying it. The I/O linc that monitors the state of my garage works pretty well, but seems to be the exception.

About a year ago, I started to develop my own Insteon daemon for Linux with plans to implement a full HA system. At this point, I have a small daemon that can operate all of the devices I have listed above (and most other Insteon gear), and have gone as far as implementing LuaUPnP code to drive on/off switches and dimmer switches through my system. (And yes, flipping the switch at the wall updates the UI state as long as there is a link to the PLM.)

Since I like the Vera3 UI, I plan to continue to expand my LuaUPnP interfaces for other devices that I have. (FWIW, I have just about 1 of every piece of Insteon hardware you can currently buy on the Smarthome site.)

I have noticed a lot of other posts on the forum indicating that they want to do Insteon related stuff that doesn’t seem to be supported by the existing implementation. So, I am wondering if there is enough interest out there for me to adapt what I have been working on to be more suitable to run as a fully controlled daemon on the Vera3?

Are other people interested in something like this?

One of the things holding me back from releasing it is figuring out how I would support the costs of maintaining it. There are a lot of devices that I will probably never use that I have had to purchase so far in order to get the implementation working. I imagine there will be new devices in the future that I will need to pick up. If there is enough interest, does anyone have any suggestions on how to cover those costs?

If you are interested, please reply and let me know what kind of functionality you would like to see. I will make my decision based on the response that I get, so even a response of “Yes, please. I have devices X, Y, Z that I would like supported.” will help me!

Thanks!

EDIT (4/21/2012) :

NOTE : Getting Altsteon up and running takes some understanding of Linux. If you are unsure how to scp something from one machine to another, or figure out the device name a USB->Serial adapter has been given, you should probably wait to see if an easier solution comes along!

I have been asked to keep this post up to date with the latest status. So, I’ll do my best.

Altsteon currently works on the Vera 3 only. The only want to use a Vera 2 right now is to run the daemon portion on an x86 Linux box. (EDIT 4/28/12 : Vera 2 binaries are now available. Download the attachment from this post http://forum.micasaverde.com/index.php/topic,8910.msg71493.html#msg71493 Future releases will contain the Vera 2 binaries in the tarball.)

UI5 is the only UI version that is tested. It may work on earlier versions, but it has not been tested and I have no plans to test it. However, all of the documentation you would need to add support is included in the Altsteon tarball.

At this point, the majority of Insteon devices are supported. Many are buggy. However, I do run this in my own home, and Mrs. FBA seems to be generally pleased with the results.

Someone also posted and said that the Altsteon pieces can be downloaded from the app marketplace. This shouldn’t be possible as I have not yet submitted the app for approval. However, if it is visible, I highly recommend AGAINST using it. The latest patches may not be in there, so you may have to deal with bugs that have been resolved.

And, a final word. This project is something that I work on as I have time, for my own purposes. It isn’t supported by MCV, or even myself for that matter. I do attempt to help people the best that I can, but bug fixes and question responses may have significant turn-around times. There are others on the forum who can also help, so posting is a good idea if you are stuck. Just please treat all with respect as anyone that attempts to help you is doing it out of the goodness of their heart. (Quick side note. I have not had anyone on this forum be disrespectful, and hope I never will. But, I have done other projects where people have been awfully rude to people trying to help them.)

Yes! I have experienced the same issues that you are experiencing and have gone as far as purchasing the iVera app for the iPhone that mirrors the UI and other strange results when a state is changed on a switch. I use the smartlinc and keypadlinc switches mostly.

If it works as you indicated, MiCasaVerde should purchase what you have written to help their current and future customers. I have supported and convinced others to purchase this product with caution and would push the product a lot more if these features were fixed and followed their “Easy as 1-2-3” philosophy. If they do not have the development staff to create the product, they should certainly support you in their efforts by at least paying for your costs to enhance their product.

As of right now the current implementation of insteon in vera is only one way. So that is why when performing an action on the switch itself does not report the status back to Vera. Sounds like you have a nice working solution. Hopefully there will be some interest. Best of luck.

  • Garrett

It has been a while since I originally posted this, and the response has not been overwhelming.

That said, I think this may be more of an “if you build it, they will come” situation so I have been pushing ahead with the project to make what I have play nicely with the Vera.

In a bit over a week, I have on/off (relay) switches working (DevCat 02), dimmer switches working (DevCat 01), keypadlincs basically working (still trying to figure out how best to represent the scene buttons), the I/O Linc (DevCat 07), the 2420M motion sensor (motion mode only), the triggerlinc sensor, and the Morning Industries door lock controller. For everything listed, except the Morning Industries lock controller, doing something at the physical device will be reflected in the UI. (i.e. Turn a light on at the wall switch, it will show up in the UI as on without waiting for a poll.) The lock controller is only a one-way device, so the missing support there is a device limitation. ;D

With the exception of the on/off switches, everything listed above is very basic support. For the on/off switches you can control the on/off state of the LED on them in addition to the basic functionality. Eventually, I want to have all of the functionality of the devices exposed in some way, but I am starting with a few tests and the stuff that I need to retire my home-grown scheduler with the Vera.

The daemon portion supports just about all of the devices you can currently purchase, so the things I am listing above are things that I actually have working in the Vera UI.

Right now, the daemon uses a configuration file to know which devices to talk to and runs on a standard Linux x86 box. Eventually, I want to be able to run the daemon directly on the Vera. But I am pretty time constrained so I’ll get things out as I have time. Once I can strip out the need for the configuration file and write some basic documentation I’ll put it up somewhere so people can start to play with it.

I plan to post to this thread every now and then so that people can see how things are progressing. As soon as something is ready, I’ll post links here. That said, I don’t expect to have anything ready for people to play with for another couple of weeks.

Glad you are going to continue progress. This will give more people options and I am sure over on the insteon side, people will like that there is another option for them.

  • Garrett

fba,

I really like your idea and would be happy to help with testing and perhaps some development work, as well. I have just begun to outfit my house with z-wave and Insteon. So far, I have an IOLinc and OutletLinc that I cannot get my Vera 3 to recognize. Vera also does not recognize my KeypadLinc dimmer or TirggerLinc. If you have any insight on how to get these devices into Vera, it would be greatly appreciated. Vera does recognize my SwitchLinc (both dimmer and on/off). I have an InLineLinc on the way, and I’m not very optimistic about the likelihood that Vera will recognize it.

I look forward to hearing more about your work, and I'm willing to help out.

-rws

rwstrick,

Glad to hear there are others out there that would value this. Right now, I have Keypadlinc dimmers, IOLincs, Triggerlincs, motion sensors, switchlinc (both dimmer and on/off), basic thermostat support and the morning industries locks working through the Vera. Pretty much everything else is supported in the daemon, I am just fighting my way through the learning curve for the LUA code so movement can be a little slow at times.

I don’t have an InLineLinc to test with, but I suspect it will look to the Vera like a normal on/off switch.

I am basically ready to release the initial version for people to hurt themselves with. I held off doing it last night because I believe I am close to having a cross compiler set up that will allow me to build the daemon to run directly on the Vera. If I don’t get that going by this weekend, I’ll release what I have. (Which will require the daemon run on an x86 Linux box. I plan to release binaries for 32bit and 64bit x86 machines.) If I do get it done, I’ll release a version that has binaries for x86 machines and the Vera.

As it stands right now, once you get it set up it seems to work well. My Vera is turning on my garage lights and the backlight on a keypadlinc when the garage door opens. Locking my Morning Industries lock when I press a button on a keypadlinc that runs a “Good night” script that turns off all the lights in the house. It is also setting the dim level on some dimmers in the evening so that I don’t hurt my eyes when going in to the bathroom during the night.

I am not using the triggerlinc or motion sensor in any scenes right now, but I have done some testing with them to verify that they work. At some point I plan to put triggerlincs on all of my windows so that it will shut off the thermostat when a window gets opened. (My mother-in-law likes to come over and open windows at random without saying anything. ::slight_smile:

So, hopefully we can get your Vera to be able to control your Insteon devices as early as this weekend!

Great timing as I just got the motion and can’t get it talking to my vera. It never is recognized.

Hi all,

I think my implementation is ready for people that are interested. Please be aware that setting it up isn’t going to be as simple as the built in Insteon implementation, so please read the documentation!!!

In the tarball at the link below, you will find the various XML and JSON files that need to be uploaded in to the Vera. There are also three directories with binaries. You only need the binaries from one of the directories, depending on what platform you want to run the daemon on. There is an x86-32, x86-64, and MIPS binary. The MIPS binary can be loaded directly on the Vera. (If you do load directly on the Vera, the IP address you should use for the PLM configuration is 127.0.0.1.)

I have only tested the x86-64 version, but I did verify that the MIPS version will at least start on the Vera and that the ‘file’ command claims the x86-32 version should work. If you use one of these binaries, please post and let others know if they work or not.

To get it, go to :

http://www.geektaco.info/altsteon/

This that work for me (please read the docs for more info) :

  • PLM (of course)
  • Relay (On/Off) devices except the relay version of the keypadlinc (DevCat 02)
  • Dimmer devices including keypadlinc, but will probably change in the future (DevCat 01)
  • I/O Linc
  • Morning Industries Lock Controller
  • 2420M Motion Sensor
  • Triggerlinc
  • Thermostat

Devices like the appliancelinc and outletlinc will probably work, but I have not tested them as I don’t own any.

Could you give me an example of a linux box you need to make this work.

thanks

Any old x86 or x86-64 machine with a way to connect a PLM should work. The daemon spends most of its time waiting around for events, so it isn’t processor intensive. My original plan was to embed it on a 1Ghz beagle board with 256Megs of ram (IIRC).

Personally, I am running it on a quad-core Phenom II Black. But, that box also runs my MythTV system, web server, MySQL server, Samba server, and probably a few other things I can’t remember.

I developed it on Ubuntu Server 11.10 x64. However, it is statically linked, so it should run on other Linux distros as well. So, in a nutshell, if you can run Linux on it, and it is an x86 box, it should work.

fba,

I’m running all macs at this point. I would think that a UNIX executable should work but no joy. How does one go about installing the vera binaries directly? Will both the daemon and the client run on vera? I am excited about starting to play with this.

Another question: From the instructions it looks like one can add Insteon devices to vera without hitting any buttons on the deivces. As all as you know the Insteon IDs you’re good to go, right? (I have an inline-linc in the ceiling that I do not want to dig out!)

Thanks for all the hard work! The instructions make it look like there’s a lot to play around with!

BTW, I am running a vera 3. All my gear is new because I’m just getting started.

rwstrick,

Right now, you have to either manually create the links, or find an alternate way to create the links. I believe that the implementation in the Vera will create the links when you add a device. So, you could enable the Vera implementation, set up your in-line linc with that. If you can control the in-line linc with the Vera at that point, then you should have the linc already built. Since the links live in the PLM, you can turn off the native implementation, switch to my alternate one, and everything should work.

At some point, I want to hook up the “Configure node right now” button to check and build the links, but I have not gotten that far. Right now all of my devices are accessible. However, that will change in the next few weeks as I have ordered two of the new fan controllers that were just announced.

The way that I loaded the binary on to the Vera3 for testing was to use scp. I have never used scp on a Mac, but I have used ssh on the Macs that I have, so it is likely that scp is there as well.

To copy it over with scp you will need the root password for your Vera. There are a few threads on here about getting a root shell on the Vera if you run in to problems. However, the short version is on the bottom side of your Vera there is a sticker with a root password on it. If you aren’t sure if you have the right password, you can ssh in as root and see if the password works.

To scp the file over, you just need to fire up a terminal window, change in to the directory where the vera binary is, and run :

scp ./altsteon root@<vera’s IP address>:/overlay/sbin/altsteon

Once you have done that successfully, you will need to ssh in to the Vera and manually start the daemon. It is probably possible to write some LUA to run at startup that will load the daemon, but I have not looked in to that yet.

Also, you will want to be aware that I have found a bug where adding new devices may not behave correctly if the daemon has been running for a while. I am not yet sure how long “a while” is, but if you reach a point that adding devices doesn’t seem to be working, restart the daemon and try again. When you restart the daemon, you just need to hit the “Reload” button in the UI to get everything synced back up.

fba,

I’ve been trying to run altsteon directly on vera3 with limited success. I have copied the executables (daemon and client) to vera and uploaded all of the vera_files. I added the plm to the vera dashboard per the directions and without issue (as far as I can tell). However, when I create a switchlinc dimmer device, I run into trouble. The device shows up in vera as a dimmer, but when I attempt to turn the light on via vera, I get a pop-up with a “Device not ready” warning. And, when I turn the light on or off from the switch, vera does not update the dashboard item.

When I created an IOLinc device in vera (per the instructions), one device appeared in the devices list. The icon for that device was the same as the plm icon. No sensor or relay devices appeared to be created.

Finally, I tried running the _cli executable on vera. It was able to successfully switch the SwitchLinc Dimmer mentioned earlier on and off (and set brightness…essentially all control aspects seemed to work). My InLineLinc Dimmer worked just like the SwitchDImmer. However, I could not determine what device id to use for my IOLinc to get it to response to relay commands.

One more issue that has been causing problems: lately, when I try to run altsteon, I get an error message that indicates that the “PLM didn’t respond!” I assume that the daemon quits at that point, but I’m not sure. It never shows up on “top.” What command line should I use to verify whether altsteon is running? If I need to stop altsteon (as mentioned in the instructions in a number of places) how should I do that?

Thanks for all of your wonderful work. I’m really looking forward to having this tool in my home automation arsenal. (BTW, you mentioned that you have one or more FanLincs on order. I am very interested to hear your experience with those…both on their own merits and wrt altsteon.)

Thanks again,
-rws

PS – None of the executables appear to run natively on my macs. This seems strange since the macs do identify them as UNIX executables. Any thoughts? I’d still prefer to run altsteon directly on vera, but there may be some value in testing the setup on my mac prior to putting everything on vera

Looks like these binaries are meant for linux platform and not the mac platform. The mac platform is unix based yet different from linux. So these binaries will not run on the Mac.

  • Garrett

rwstrick,

Sounds like you are close to getting things working. Let me start with the easy one.

As garretwp mentioned even though the binaries are for a Unix system, not all Unix systems use the same binaries. I do have some Macs laying around the house, so I’ll see if I can do a build. There isn’t anything Linux specific in the code, so it should build okay.

For the devices you are trying to add, if you can use the cli program to control them, you are well on your way to having things work. If you are getting the “Device not ready” message a couple of minutes after getting everything running, then there is probably something not quite configured right. I say a couple of minutes because there is a fair bit of startup chatter that alsteon does with the devices so that it can try to keep things in sync. As you add more devices it will take longer each time you start up altsteon. (Hitting the reload button doesn’t restart it, so it shouldn’t take more than a few seconds to reload once it has been running.)

The first thing I would try doing is hitting the “Reload” button on the Vera dashboard. This will make sure that all of the pieces get loaded correctly and start running. When the “Server busy” message disappears from the top status box, see if things start to work. If everything is configured correctly this should also cause your IOLinc to create its children devices.

If that doesn’t work, I would check is that the dimmer device’s parent is set to the plm. If you look at the vera_settings1.png file I have attached you will notice that “Controller via” is set to “plm”.

Then, make sure the “device_type” is set to “urn:schemas-upnp-org:device:DimmableLight:1”. (It sounds like you have this correct already if you are seeing the dimmer controls in the dashboard.)

The next thing to check is the value of the altid. The Vera implementation crunches the id down from whatever format you use to something like “123456”. Altsteon uses the same format that is printed on the stickers for the device. So, the same device would be entered as “12.34.56”.

Finally, make sure your “device_file” is set to “D_DimmableLight1.xml” and the impl_file is set to “I_InsteonDimmer.xml”.

If any of the settings I mention above are wrong, then things won’t work correctly. Also, everything except the altid is case sensitive. So “d_dimmablelight1.xml” is different than “D_DimmableLight1.xml”. For the altid, the letter portions can be upper or lower case. So, “1a.2b.3c” is the same as “1A.2B.3C”.

As for the “PLM didn’t respond!” error, while writing altsteon I have seen that come up in two different cases. The most common is when the PLM shows up as something other than /dev/ttyUSB0. From the Vera shell, you can get an idea of the device in use by running 'dmesg | grep “ttyUSB”. You should see a line similar to this :

usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0

If that says anything other than ttyUSB0, you will need to start the altsteon deamon with the -d command line option. In general, if you leave the PLM plugged in to the Vera it should always come up the same. But, if you unplug it and plug it back in sometimes Linux will put it on a different device.

The other way that I have seen the PLM not respond is if there is another copy of altsteon running. Linux can get pretty grumpy when two different programs try to access the same serial port at the same time. It is easy enough to see if the daemon is running by running ‘ps xaf | grep “altsteon”’. If it is running and you need to stop it, you can use “killall altsteon” to kill the daemon.

FWIW, I have a fix to the issue that causes it to be necessary to restart in many circumstances. I had planned to put that out last night, but it wasn’t quite ready. So keep an eye open this weekend.

For the IOLinc, the main device will have the same icon that the PLM does. This seems to be the default icon that the Vera uses when it doesn’t know what else to use. However, if you didn’t get the relay switch and sensor devices then something is configured wrong. When the Vera starts up, it should run the code in I_InsteonPlm.xml to get all known devices set up with altsteon. Once that code is run, it should run the code in I_InsteonIOLinc.xml which will create the two sub-devices. So, the code in I_InsteonIOLinc.xml isn’t getting run. This could be because the plm isn’t set up with the I_InsteonPlm.xml file, or because the IOLinc isn’t set up with the I_InsteonIOLinc.xml file.

I intend to make some of this a little easier to work with, but I don’t have a lot of time to work on it so it doesn’t move as fast as I would like. :wink:

As for the fanlincs, I got an e-mail claiming that they started to ship them, but I have not seen a tracking e-mail to indicate that mine have shipped. But, I’ll be sure to let you know what I think of them once I have them.

fba,

Thanks for the generous notes. I have been able to avoid the PLM error messages based on the information you provided. I have also been able to get a SwitchLinc Dimmer to show up in vera and to respond to on and off commands from vera. I have noticed, however, that vera’s status info does not update (at least not at all quickly) when the switch is controlled at the switch or via another Insteon switch. I was hoping that the switch would tell vera when its status changes. Is this type of instant response available through vera/altsteon?

I am still having difficulty getting child device to show up for Keypad Linc DImmers and IOLincs. I also noticed in your documentation that the child devices for a KPLinc Dimmer are BinaryLights. These secondary buttons are capable of controlling dimming functions on another switch. Why are they defined as Binary rather Dimmable?

I look forward to the release. Thanks again for sharing your work.

-rws

Hi rwstrick,

When I toggle a switch at the wall it can take a second or so for the Vera to show the update in the dashboard. However, it sounds like you are waiting a fair bit more than a couple of seconds.

The daemon automatically polls devices every 10 minutes. This is because once in a while messages get lost on the wire. However, in my experience it is either once in a great while, or else caused by something like having devices on different phases and no wireless devices to bridge the phases. So if it is only updating after minutes of waiting, it is being updated by the poll. My first question would be if you have the switch linked to the plm? If you don’t, then the messages indicating that the switch changed state won’t be picked up by the plm, which in turn won’t update the dashboard. To fix this, you need to put the switch in to linking mode by pushing the little button under it and holding it for ~3 seconds. (Or, until it beeps, if it is one of the devices with a beeper.) Then, go to the plm and push the button on the side for ~3 seconds until it beeps. The order is important. You want the switch to be set up as the controller and the plm as the responder.

For devices linked to other devices, such as a three way switch, the updates are going to be hit and miss. When a responder gets a message to do something, it doesn’t send a message out to all of its responders. As a result, in something like a three way switch you will only have one of the switches showing the correct state. I have all the bits in the daemon to track the relationships, but I have not fleshed out the functionality completely.

For the keypadlincs, you will probably want to hold off on doing much with them for now. In the next release it won’t create an array of switches. Instead it will create a single switch and a scene controller. This seems to me to be the right way to handle it. (However, I am open to good reasons that I am wrong. :wink: It didn’t make sense to me that each button would be seen as a switch because the button itself doesn’t actually control a load. The device controlling the load is what should show its current state. Since a keypadlinc can control a load, the first button should show up as a real device. (To be fair, it may not always control a load. I have two kpls that don’t control loads.) As a scene controller, it doesn’t matter if the buttons can dim or not. That isn’t something understood by the Vera. (A scene is either on or off, even if “on” means a light is at 2%.) — However, again, I am open to good arguments why I am wrong. :wink:

For the keypadlincs and dimmers, double check your settings, and make sure you have a link from the device to the plm. (The plm ignores messages from devices that are not in its all-link database.) If the plm is unable to talk to the device, then it can’t figure out that it is an IOLinc or KPL, so it doesn’t do anything. For the KPL, if you want the scene buttons to control an event on the Vera you will need to individually link those as well. The linking procedure for a button is similar to a device. You just press and hold the button for ~10 seconds (or until the kpl beeps), then go push the button on the PLM for 3 seconds. At some point I plan to make altsteon smart enough to check this and build links for you, but for now you have to do it manually. (My goal right now is to get as many devices supported as possible, then I’ll go back and add some of the “nice to have” stuff.)

The child devices for the IOLinc and KPL are created when code in their respective I_.xml files is executed. If the IOLinc and KPL aren’t set to be controlled by the plm, that code won’t get run. Also, if there is a typo or some other reason that the Vera can’t find the I_.xml file for the device the code also won’t get executed. Unfortunately, the Vera doesn’t really provide much help when you get something wrong. If you are watching the logs on the device, you will see some red text scroll by that indicates that LUA tried to access something that was null. You may also see some messages indicating that files couldn’t be loaded. If you feel like digging in that far, you can ssh in to the Vera, change to the /var/log/cmh directory, and run ‘tail -f LuaUPnP.log | grep “^5|^10”’ then click the “Reload” button on the web interface. But, make sure your ssh client is set to let you scroll back quite a way. A lot of stuff can hit the log when the Vera is reloaded.

If I have time, I’ll also add some code to the next release to double check the settings and fix them if they are wrong. There is already code in place to do this for the relay switches and it seems to work well. So adding it to other devices should be easy enough, just time consuming.

BTW - I double checked my order status last night. I was wrong. The fanlincs were already shipped and should be here sometime today. I did a blind implementation for them in altsteon last night, so once I have them it should hopefully only be some small bug fixes and the support will be in place to add the files to the Vera.

I have released Altsteon 0.02. It can be found at http://www.geektaco.info/altsteon/ . You will want to upload all of the LUA plugin files included in this version, even if you have uploaded them before. There are a lot of subtle changes to those plugins.

Changes in this version :

  • No longer need to restart the daemon when a device is deleted. Deleting the device from the dashboard, and then hitting the “Reload” button will do.
  • Support for GarageHawk (both Garage and Remote components)
  • Support for IRLinc (Will show up as a scene controller where Scene A = Scene 1, Scene B = Scene 2, etc.)
  • Support for Remotelinc 1 (May work with Remotelinc 2, I don’t have one to test.) (Like the IRLinc, it will show up as a scene controller. Scene A = Scene 1, Scene B = Scene 2, etc.)
  • Blind support for the relay style keypadlincs. (People will have to let me know if this works or not.)
  • Changes to how the keypadlincs work in the dashboard. (Keypadlincs will now show up as a single switch, and a scene controller. If the keypadlinc is a 6-button, then Scene A = Scene 3, Scene B = Scene 4, etc. If it is an 8-button, Scene B = Scene 2, Scene C = Scene 3, etc.)

Things I didn’t get to that I will try to get in the next release :

  • Improved “ease of use” when adding devices to the dashboard.
  • Mac OS X version of the daemon for testing.