I set up an I/O Linc in my garage with a magnetic sensor (the kit Smarhome sells). The relay works (although clunky as only the “on” works, not the “off”) but the sensor always shows the sensor as closed. Can anybody give me some ideas of what to check? I had the kit installed in my previous home, so I know it worked at some point (under mControl…)
If you are able to control the relay, the communication between the PLM and the io Linc should be good. So you either have a hardware or link issue. Checking the hardware should be fairly easy. The green led on the front and bottom should light up when the door is in one state, and turn off when it is in the opposite state. If that doesn’t happen, then you may have the sensor wired wrong. If that works then you probably don’t have a link between the two devices. Relinking them should resolve that issue.
I am having a similar issue. I know the hardware is good (the green light, turns on and off as expected). Fba, can you give a quick how-to on unlinking and relinking with Alsteon?
What I am seeing is when I am looking at Altsteon command line I can see when the contact is active and inactive, but the Vera interface does not update. It just shows inactive (green). Any idea why this is happening? The daemon seems to get the command, but nothing happens.
Wow, I guess no one knows?
Specifically what I have is when the sensor it open, I get the following in the CLI: xx.xx.xx:000A,02 - Contact is Open
So I know the daemon can see the event, however, Vera never shows the sensor in alert.
Any ideas?
If the daemon is seeing the event, then the problem is with communication between the daemon and the Vera UI. Is this the first device you have set up? Or do you have others that are working properly?
I have 4 switchlincs, 1 outlet and 1 appliancelinc that work fine (I can control them from Versa and see their state even if manually controlled).
However, my Keypadlinc is in the same state. I can see the button presses in the daemon, but Vera can’t see them (I am not sure if it is set up correctly anyway).
Thanks for replying fba, I was going nuts trying to get this working.
Sent from my EVO using Tapatalk 2
Make sure you are on the right terminals on the IO-Linc, it has normally open and normally closed contacts to monitor the status of the garage door. There is also a chance that the system defaulted during reinstallation. Making your door control relay, a maintained contact, instead of momentary. Do you need the paperwork for the kit you bought? If I can help , Let me Know…
First: I am sorry to have hyjacked swazi’s post.
mo42556: I am sure that I am on the right terminals, because I can open the garage door via command line and the Vera interface. I can also see the contact opening and closing via the command line, but the changes are not reflected in the Vera interface.
Anyone have any ideas on how to solve this issue? I am desperate to monitor my garage door, I am about ready to either by a Z-wave sensor or re-install mControl. Any help would be appreciated.
Sorry, I have been mia for a while. If we are the only ones with this problem then I would venture a guess it is a hardware version issue. Mine is a few years old. I will try to look at the version number this weekend. How about you? If that is the case I think we are sol.
Been MIA myself for quite a while.
If you are seeing an event via the command line, then everything is working correctly from the Insteon side of things. So, the problem is that the information isn’t flowing from the daemon up to the UI correctly. Could you connect with the cli, open and close the door, and send me the output? I am wondering if you are seeing a set of codes that aren’t understood by the LUA code.
If I remember correctly, this insteon unit has two addresses. You can consider it both a slave and a controller. I will be working on it later and will have more info if I can get it going for you later. I am just starting to set up my veralite. Others have had some problems getting it working using other systems, such as isy99. You might try some other forums for more info on this I/O device.
[quote=“fba, post:12, topic:171902”]Been MIA myself for quite a while.
If you are seeing an event via the command line, then everything is working correctly from the Insteon side of things. So, the problem is that the information isn’t flowing from the daemon up to the UI correctly. Could you connect with the cli, open and close the door, and send me the output? I am wondering if you are seeing a set of codes that aren’t understood by the LUA code.[/quote]
Glad to see you are back! When I get home tonight I will grab the exact output and post it. Thanks.
This is what I get when I open and then close the door.
19.5F.2D:004A,02 - Sensor is inactive.
19.5F.2D:004A,00 - Sensor is inactive.
19.5F.2D:0049,02 - Sensor is active.
19.5F.2D:0049,00 - Sensor is active.
FWIW, I know that what you are trying to do will work. I have an IO Linc set up to monitor one of my garage doors, and it works great. There is a short in my opener that keeps the light from coming on when the door opens, so I have the lights in the garage come on instead. (But, only when it is dark to save some money.)
Do you have any other Insteon devices installed and working? (Light switches, etc.) It would be good to verify that the PLM is configured correctly. The way the events flow through the system is that the PLM code dispatches events to the other devices. So, if the PLM isn’t working correctly nothing else will get events, and nothing will seem to work. For the next release, I am going to add an indicator to the PLM tile that will show if it is communicating with the daemon or not.
I’ll also have a look at the code tonight and see if I can see any reason it wouldn’t be working. I know there are some bugs in the IOLinc code, so you might be triggering one of those.
Thanks for looking into it.
Yes I have many other switches that are working (with the exception of my SwitchLinc, see my other post). I have 4 switches and 1 outlet that operate perfectly.
Sent from my EVO using Tapatalk 2
RyanAHolland,
I didn’t get a chance to look at it last night. I ended up having to work late. I am doubtful I will get to it tonight either with all of the kids at my door looking for candy. But, I should be able to look at it tomorrow night at the latest.
fba,
No worries man. BTW, do you have a donate page set up?
Sent from my EVO using Tapatalk 2
Okay, I should probably stop promising to do things on certain dates. Life seems to get away from me sometimes. 
Looking through the LUA source for the IOLinc, it appears that the values you are getting are correct. (I_InsteonIOLinc.xml, lines 67 & 72 or 73 for those that want to follow along at home.) So, there are a few other places that the problem might happen.
These are the thoughts that I have :
- For some reason, the events aren’t making it up from the daemon through the PLM XML (I_InsteonPlm.xml) and down to I_InsteonIOLinc.xml, which would prevent the state variables in the Vera from being updated, and cause the state not to be correct.
To troubleshoot that, I have attached a version of I_InsteonIOLinc.xml that will log the lines “Setting sensor NOT tripped.” when the sensor is closed, and “Setting sensor tripped.” when it is open. If we use the attached version, there is some other logging that will also be helpful.
Once you have that loaded on, ssh in to the Vera and enable your ssh program to capture the SSH session output. Then, tail the LuaUPnP.log file in the in the /tmp/log/cmh directory and in the Vera web interface, click the Reload button. Now, wait a while. I would think 5 minutes would be enough.
Then, save the SSH capture file, and open it up in a text editor of some sort. Use the find function to see if you can find the text “*********** Sensor Id :”. If it is there, then we know that the Vera is configured to talk to the IOLinc, and it is being detected properly. Check the UI, and make sure that the IOLinc is represented by three devices. One should be named and have the three colored gears for the icon, and no buttons on the tile. One should be named “ (Sensor)” and should have an “Arm” and “Bypass” button on the tile. One should be named “ (Switch)” and should have a on and off buttons on it.
If you can’t find the text, or the tiles don’t look the way I describe, then you will want to double check the settings in your configuration to make sure they match what is in the altsteon_instructions.txt file. If they do, let me know and I’ll send you screen shots of my working config so that we can see if the documentation is wrong.
If all of that looks good, then we will move on to idea #2.
- If the tiles are all there, and the text for the Sensor is in the log capture, we need to make sure that we are actually seeing the events. So, set up the capture and logging the same way that I outlined in #1, but this time open and close the door. Save the capture data, and search the text for “Setting sensor NOT tripped” and “Setting sensor tripped”. Both should be in there. If only one is in there, then we will need to figure out why, which will take some LUA hacking. (I can take you through that if we need to.)
If the text is there, then we move on to idea #3.
- The states on the tiles are drawn based on the variables that get set in the I_InsteonIOLinc.xml. If the values are being set, but the tiles aren’t updated then the service file may not be getting loaded, or the UI files may have incorrect values. This one is going to be more difficult to troubleshoot. But, one thing you can try is setting up a light to turn on when the sensor is tripped, then open the garage. If the light comes on, but the UI doesn’t update, then we have to dig around in the UI files to see where the disconnect is. If the light doesn’t come on, find a brick wall and pound your head against it, then respond here so we can formulate a new plan of attack.
As far as a donation page, I don’t have anything set up right now. I have been thinking about it, mostly as a way for people to easily send me money if they wanted to see a specific device implemented. But, at the same time, it would be nice to have a little stash of cash to buy the new devices when they come out. I’m not a big fan of PayPal, but I’ll look in to it and see what I can do. There are several new devices coming out (not sure what has been announced yet other than the water sensor, but there are some new spec sheets in the developer area), and it would be nice to be able to support them.