Altsteon and SwitchLinc V2

Other Devices & Integrations More Home Control
1

Hi,

I’m moving from another control system to Vera 3 and need to migrate my current Insteon devices. I tried out the native implementation and then found out that the Insteon 2420M motion detectors don’t work will with it and so started investigating Altsteon. Thanks to fba for that!

I downloaded and installed the latest version on my Vera 3 and did the simply test of adding a device via the CLI and then trying to manipulate it. Unfortunately for me I started with a SwitchLinc V2 Relay. I can’t seem to get Altsteon to communicate with these devices, although I have had success with ApplianceLincs, LampLincs and the motion detectors.

I’ve verified that the SwitchLinc V2s or linked to the PLM (2413U) by stepping through the aldb_recs in the altsteon_cli.

When I try to add one of these via the CLI the Altsteon daemon complains about DevCat FF, says it can’t create the device, but will poll for it. It does seem to eventually find it but still has problems communicating with it. See the attached log.

For what it’s worth, these SwitchLinc are 5-6 years old. The version number on the ones I’ve check are 2.3. On the other hand, they did work with Vera’s native Insteon support.

Thanks for any help.

2

Hi dlb,

Welcome to the forums!

In the log you provided, I see one thing that is a potential problem (but probably isn’t) and two things that are certainly problems.

The potential problem is that the device is returning messages with a hop count of 0 in at least one response. This can mean that your device is far enough away from the PLM that you may occasionally have problems. That said, the device responds to every request that is being sent by Altsteon. So while it is a potential problem, right now it isn’t one that is causing the issues you see.

The next problem is with the engine version of the device. From the log :

[6/5/2012 - 16:54:52] - Got engine version 0.

There are three different engine versions that have existed. When the value returns 0, it is an i1 device. When it returns 1, it is an i2 device, and when it returns 2 it is an i2cs device. (i2cs devices have only been available in the last few months, so there aren’t a ton of them out there yet. Unlike the i1 devices, I have a few i2cs devices and know that they work.)

So, why is this a problem? The old i1 devices liked to use PEEKs and POKEs to get some of the information out of them. Altsteon doesn’t implement those calls because I don’t own any devices that I can test against. However, the only thing that Altsteon is using that would use PEEKs and POKEs is the ALDB. In i2 devices, there was a command introduced that dumps the ALDB directly. You can see this from one of your devices that is working with the command “aa.bb.cc dump_aldb”.

Altsteon wants to know the information in the ALDB so that it can do its own internal updates of devices. Based on how the Vera works, I am not sure that these updates are needed, rather it is leftover code from what Altsteon was originally intended to be. So, I’ll need to decide how best to handle this. I can either disable that functionality for i1 devices, or spend the time to figure out if it really breaks anything if I disable it for all devices. So, that is one of the issues you are hitting.

The other issue you are hitting is a genuine bug. (In my code? Say it ain’t so Joe! :wink: For some reason, the daemon believes that it should treat your i1 device as an i2cs device. This is probably what is creating all of the non-response issues you are seeing. In a nutshell, with Insteon there are two different lengths of commands. The SD and the ED commands. (Though there are variations on those for things like broadcast, but that isn’t important for this discussion.) With i2cs devices, some commands that were previously SD commands have become ED commands with a checksum at the end. (The checksum is the ‘cs’ in ‘i2cs’. :slight_smile: As a result, your i1 devices are being sent commands that they have no idea how to handle. So, they will usually discard the commands and just not respond. Altsteon handles this by putting the command back at the end of the queue and trying again later. (It is a vicious cycle at that point.)

So, by far, the most important question of this e-mail is, “What can I do to make it work?” Unfortunately, the answer is “Nothing but wait.” I’ll put these issues high on my bug list and try to get them fixed an in a release within the next month, but I promise nothing. (I had a big load dropped on me at work yesterday, so some of my Altsteon time will likely go to getting the work done so the product can ship.)

For completeness sake, let me address the “DevCat FF” complaint you saw. It really isn’t intended to be a complaint, as much as it is an informational message to help me in debugging. When Altsteon gets an “add_device” command it can be just an address, or an address followed by the DevCat and SubCat numbers. (In the case of wireless devices like the 2420M, you have to include the DevCat and SubCat numbers because the device can’t be polled.) When the command comes in, Altsteon creates an internal representation of the device, and assigns it some default values. One of the defaults is that the DevCat and SubCat both are set to FF, which is an invalid Insteon DevCat and SubCat. When Altsteon’s work loop comes around to a device that has this invalid setting, it stuffs a command in the devices command queue that is used to go out and ask for those values. Those values are then used internally to know which commands can be sent to which devices. Once Altsteon gets an answer, it adjusts how the in-memory representation looks so that it is now aware of commands that are valid for the device. As an example, if the DevCat is showing FF, and you manage to get a command like “aa.bb.cc get_devopts” in the queue before the command to determine what the device is, you will get an error that the command is invalid. In reality, you may know the command is perfectly valid, but Altsteon doesn’t know that until it has figured out what type of device it is. When the DevCat is FF, there is just a tiny subset of commands that will work. Most of the commands are used to figure out what the device is.

3

Hi fba,

I doubt that distance from the PLM is an issue, since I’m pretty sure that the SwitchLincs that are problematic are on the same circuits/phases as other devices that are responding okay. Plus, it is only the SwitchLincs which are probably the first Insteon devices I bought that are the problem. Devices that are responding are in the same rooms as the SwitchLincs that aren’t.

If access to older SwitchLincs is an issue, I have some extra SwitchLinc 2 Relays. I could send you one if that would help. Let me know if that would help.

Thanks - David

4

Hi dlb,

That’ll teach me to write long rambling responses when I am tired. I didn’t mean to suggest the distance was the primary problem. The primary problem is the other things I listed. My comments on the distance were more intended to be a warning. However, there are plenty of reasons that you might get 0 hops remaining and have no problems with the performance of the device. I probably should have left those comments out to avoid muddying the waters. Sorry for the confusion.

Last night I removed the ALDB calls from the startup chain for the devices. If you would like a development build to see if it resolves the problem, I would be happy to give you one. (Just let me know.) But, be aware that I am in the middle of some work with ser2net that may cause more problems than it solves. That said, I am running that code right now and it seems to work okay.

5

Thanks fba,

I’d be glad to try out a development build. Just email a link or an attachment and I’ll let you know if it solves my problem.

Or send it via PM. New to the forums and just discovered that feature…

Thanks - dlb

6

Hi dlb,

Sorry for the delay. I lost a bunch of my spare time fighting with my ISP, and then switching ISPs after they made some really insane statements!

Anyway, I have uploaded a dev build, fresh of the build server to http://www.geektaco.info/altsteon/altsteon_dev_test.tar.gz . It contains everything that a normal release would, however I recommend ONLY using the updated daemon. Loading the updated xml files could easily result in major brokenness as I have a bit of work going on there for moving toward ser2net.

Please let me know if the revised daemon works for you. The changes don’t seem to have impacted the behavior of my gear in any noticeable way, so if it works for you I will leave the changes in place.

7

Thanks fba,

I’ll download it, try it out, and let you know.

So for now, I should just use the xml files, etc. from the previous release?

Thanks again - dlb

8

Thanks fba,

I downloaded and installed the dev build and it is working fine with all of my Insteon devices including the V2 SwitchLincs.

  • dlb
9

Excellent! I’ll keep those changes in future versions of the code then.

10

Hello fba,

if you can help I would like to add to my zwave network with vera3 some products insteon because the price more cheapper…

can you help me saying the products I have to buy and what I have install in my vera3 ?

thanks for your help !

11

You need to start by getting an Insteon PLM PowerLinc Modem (PLM). I believe MCV recommends the 2413U. (http://www.smarthome.com/2413U/PowerLinc-Modem-INSTEON-USB-Interface-Dual-Band/p.aspx) From there, you should be able to install any Insteon devices you want.

12

I will verify with MCV.

thanks !

13

I have been trying to get Altsteon working with my Insteon network and am having trouble. At first some of my newer devices (a few LampLinks) seem to work well, response happens and the dimmer controls work. However, I have a lot of (35 or so) older SwitchLink V2 switches which are not responding as expected. At first, Altsteon version 5 would not receive a response from the devices, always getting a time-out response. I found this thread, which sounded similar, so I loaded the above “dev” version, at first it looks great. From alsteon_cli the devices respond to on/off commands. However, the devices do not response to the “instant_dim” command, the following is a log of the event:

[11/25/2012 - 19:48:49] - 0b.7a.88 status poll result : off
[DEBUG] [11/25/2012 - 19:48:49] - Cleared active command.
[TRACE] [11/25/2012 - 19:48:49] - There are 0 byte(s) left in the buffer.
[TRACE] [11/25/2012 - 19:48:49] - No active command!?
[TRACE] [11/25/2012 - 19:49:28] - CLIENT COMMAND : 0b.7a.88 instant_dim 100
[TRACE] [11/25/2012 - 19:49:28] - Parse user cmd ‘instant_dim’ in DevCat01.
[TRACE] [11/25/2012 - 19:49:28] - Adding : 02620B7A880F21FE. Multi = false
[TRACE] [11/25/2012 - 19:49:28] - Returning new command.
[DEBUG] [11/25/2012 - 19:49:28] - Sending : 02620B7A880F21FE
[TRACE] [11/25/2012 - 19:49:28] - Found the device : 0B.7A.88 (0b.7a.88)
[TRACE] [11/25/2012 - 19:49:28] - Processing SdEcho using base class!
[TRACE] [11/25/2012 - 19:49:28] - Got an ACK.
[TRACE] [11/25/2012 - 19:49:28] - There are 0 byte(s) left in the buffer.
[DEBUG] [11/25/2012 - 19:49:28] - Response : 02 50 0B 7A 88 18 D5 6A 27 21 FE
[TRACE] [11/25/2012 - 19:49:28] - Found the device : 0B.7A.88 (0b.7a.88)
[DEBUG] [11/25/2012 - 19:49:28] - Flags : Direct_ACK Hops remaining : 1
[TRACE] [11/25/2012 - 19:49:28] - Calling 4 parameter cooked ack.
[TRACE] [11/25/2012 - 19:49:28] - 4 command SD ACK.
[TRACE] [11/25/2012 - 19:49:28] - Calling 2 parameter cooked ack.
[TRACE] [11/25/2012 - 19:49:28] - In DevCat01 cooked SD ACK. cmd1 = 21 cmd2 = FE
[11/25/2012 - 19:49:28] - 0b.7a.88 light brightness is 254.
[TRACE] [11/25/2012 - 19:49:28] - To client : 0b.7a.88:0024,01,FE - Light brightness is 254.

[DEBUG] [11/25/2012 - 19:49:28] - Cleared active command.
[TRACE] [11/25/2012 - 19:49:28] - There are 0 byte(s) left in the buffer.
[TRACE] [11/25/2012 - 19:49:28] - No active command!?

The command seems to have worked, but the light level never changed. Is there a slight difference in command structure for the older SwitchLinc devices? It should be worth noting that the built-in Insteon control was able to dim the devices, so it should be possible, somehow.

Also note that this also prevents the light from working from the Vera UI as it seems to send the “instant_dim” command.

14

I did a bit more research and it seems I might actually have older than “V2” switches, since they report Insteon protocol ‘0’. Looking into the message, the instant_dim command sends a command 0x21. It seems the original dimmers respond to command “0x11”, which is on at the saved ramp rate (exactly what I want). Is it possible to configure Altsteon to send this command for DevCat 0x01?

15

I was able to modify the function in I_InsteonPlm.xml to send the on/off commands as the V2 (or older) lights seem to require:

function setDimmerLevel(lul_device, lul_settings)
local target = “”
local newval = lul_settings.newLoadlevelTarget

local dev = string.split(luup.devices[lul_device].id, "_")
target = dev[1]

luup.log("Setting dimmer to " .. newval)
if( newval == "0" ) then
	plmSend("setloadleveltarget", "\"" .. target .. "\" off " .. "\n")
else
	plmSend("setloadleveltarget", "\"" .. target .. "\" on " .. newval .. "\n")
end

end

This works-around my problem so I can at least work with my switches, however, I can’t control the dim level. For this I think the “on” command should take one extra parameter, the level to dim to (the instant_on command can as well). I don’t see any way to do this with the current daemon, perhaps this could be added easily as an optional parameter for DevCat1 devices?

Also, great program, it works better than the build-in Insteon already :slight_smile: I am very happy with it. Is there any kind of a donate link somewhere (you should set one up if not), I would gladly thrown a little cash your way, well worth it in my book.