Altsteon I/O Linc troubles

Other Devices & Integrations More Home Control
#1

I have my iolinc linked to my KPL and my PLM. The KPL button shows the correct state of the garage door (LED backlight on for open, off for closed), but Altsteon doesn’t show the correct state until a poll happens after the state change. During the state change, Altsteon_cli shows it is receiving the previous state from the IOlinc instead of the new state. An immediate poll will return the correct state. Seeing as the KPL is responding correctly, could this be problem in the Altsteon code or a bug with the iolinc? I just got my VeraLite yesterday, so I only have a few hours experience on trying to understand how this all works. Any help is appreciated.

Door opened.
2c.44.df:004A,02 - Sensor is inactive.

2c.44.df:004A,00 - Sensor is inactive. (wrong, sensor changing to active at this point as shown in the poll immediately following)

Cmd : 2c.44.df poll
2c.44.df:0023,02 - Executing forced poll.

2c.44.df:0049,01 - Sensor is active.

2c.44.df:000A,02 - Contact is open.

Door Closed

2c.44.df:0049,01 - Sensor is active.

2c.44.df:0049,00 - Sensor is active. (wrong, sensor changing to inactive at this point as shown in the poll immediately following)

Cmd : 2c.44.df poll
2c.44.df:0023,02 - Executing forced poll.

2c.44.df:004A,01 - Sensor is inactive.

2c.44.df:000A,02 - Contact is open.

#2

Sounds like maybe you have the “trigger reverse” setting enabled?

When that setting is enabled, the IOLinc will pretend to be opposite, but when you query/poll it, it returns the actual state.

When you linked the IOLinc and KPL, what was the state of the door? The manual (page 6) states:

NOTE: During linking, you will have the option to turn on remote INSTEON devices when either the connected sensor is closed or when it is opened. Once this is programmed, the opposite action will trigger an OFF command. For example, if you program an ON command to be sent when the I/O Linc connected sensor is closed, opening the sensor will trigger an OFF command.
http://cache-m2.smarthome.com/manuals/2450.pdf

Also, the magnetic switch SmartHome sends is usually replaced by the end user with the opposite type, so that “closed” equates to “off.”

#3

The door was open when I linked it to the KPL and the PLM, because open should be when it is on. The KPL reflects this correctly.

Also page 6 of the manual.
“Put your sensor into the state you want to use to trigger I/O Linc to send an ON command. For example, if you want closing the sensor to send an ON command, close the sensor.”

I am using the magnetic switch from the garage door itself. It has it’s own open and closed limit switches on the rail. I tied into the closed switch because the open wouldn’t be reliable to verify full closure. There is continuity across the leads when the door is closed, none when it is open.

#4

After doing a little digging it appears the IO Linc support in Altsteon is just a wrapper of micasaverde binary light device for the switch portion and a generic door sensor. It knows nothing about modes A, B, or C, nor does it know anything about sensor reversing that is required for a lot of configurations. I guess I will need to just get the opposite switch type and avoid reversing if I want this to work correctly, or find a way to force a device poll when receiving a status update from the sensor.

Is forcing a polling event possible based on receiving a status update?

#5

You could create a scene that runs whenever the senses trips or un-trips. Then add LUA such as:luup.call_action("urn:micasaverde-com:serviceId:HaDevice1","Poll",{},DEVICE_ID)
Replace DEVICE_ID with the device ID of the sensor.

NOTE: Be careful this doesn’t lead to a firestorm of activity. If the sensor is reversed, and it trips, it will poll, show as untripped, which causes the scene to re-run, and polls it again, but should remain as untripped.

You are probably better off swapping the sensor to be correct, so that this extra polling isn’t needed. Otherwise, you can’t really use a scene trigger for “sensor is tripped” because you’ll never know if it’s a real trip or a “reverse” trip.

Another option, although a bit more complicated, is to use a different LUA Implementation file for this sensor. It would essentially reverse the tripped/untripped LUA calls, so be correct for your environment. I attached a quick updated file. I have no way to test it.

#6

The wrong info is sent only during status change. Wouldn’t reversing the 0049 and 004a events fix it for the immediate result, but break it when the next poll comes along that reports the true value?

#7

That LUA doesn’t seem to work. I tried just the device id and it gave an error, then I tried the device id quoted. No error, just nothing happened.

#8

You are correct, I forgot the Altsteon periodically polls devices as well. I removed the file from the post.

The Poll command should work, as Altsteon has handlers for it. It might not be returning status, try adding a “return true” at the end.

You shouldn’t need quotes, if the device id is 123, use:

luup.call_action("urn:micasaverde-com:serviceId:HaDevice1","Poll",{},123) return true

#9

Ahh. I was putting in the device address, not the device ID. I had to put in the id of the iolinc parent, not the sensor child device. Closing works well, the opening scene seems to loop. I think I need to rethink my trigger logic.

#10

After running on the stock Insteon support for a bit I got an idea that could fix the reverse issue without forced polling or similar shenanigans. I noticed on the stock system the sensor is set up as a motion sensor instead of a door sensor. The only functional difference I noticed was when set up as a motion sensor, it doesn’t respond to poll requests. If altsteon set up the sensor as a motion sensor, reversing the response codes should work. Would that take anything other than a few edits of the implementation file?