Does anyone have the Insteon Motion sensor working with Vera ?
If so, how did you make it work.
On my Vera2, it can only see it as a generic device
I too am intested if this can be achieved. I’m considering a Vera2 for my Insteon network.
I have 4 of them - they work reliably as motion sensor (but light level and battery level do not report)
The key is they need to be a reasonable distance to a dual band device /plm at the fringe they come up as generic, but with better signal they report well and Vera can use them to trigger Insteon and Zwave devices.
I have been struggling with this motion sensor for a week.
Never shows as anything other than a “genericIO” :‘( :’( :‘( :’(
I have tried this at various distances from both APs and the PLM.
Any help would be great ;D
[quote=“blackgold, post:3, topic:167672”]I have 4 of them - they work reliably as motion sensor (but light level and battery level do not report)
The key is they need to be a reasonable distance to a dual band device /plm at the fringe they come up as generic, but with better signal they report well and Vera can use them to trigger Insteon and Zwave devices.[/quote]
Could you possibly share the advanced settings for your motion sensor? In particular, I’d like:
device_type (I'm assuming this to be urn:schemas-micasaverde-com:device:MotionSensor:1)
device_file (I assume this is D_MotionSensor1.xml)
category_num
capabilities
Like the others, I’ve been unable to get Vera to recognize it as anything but a generic IO, but I’ve been successful forcing Vera to recognize other devices in the past with the proper info. Any help would be much appreciated.
I, too, am trying to get the Skylink 2420M to work with Vera. I’ve got a Vera3 running UI5 and hooked to a Smarthome 2413UH PLM. Using that setup, the device IS recognized as a motion detector (provided it is close enough to the PLM - thanks for that tip). However, the behavior is pretty weird. It takes 20-30 sec after the sensor detects motion (led indicator) before Vera indicates the sensor has been tripped. Then, the sensor remains in the tripped state until there is a subsequent motion. At that point it goes to untripped in the Vera display. Not what was expected.
Checking the sensor in Houselinc 2, there is no delay in signal being reported back to houselinc and the on/off signals are correctly interpreted by Houselinc. The sensor isn’t malfunctioning. So I’m guessing that the current Vera settings aren’t correct for this sensor.
Problem is, I have no idea what to change nor where to start. The sensor, itself, has an assortment of jumpers that may also need to be set differently for Vera. If someone has the right jumper configuration, that would be great information to have!
Here’s the data that was assigned to this sensor upon adding it to Vera:
device_file: D_MotionSensor1.xml
impl_file:
category_num: 4
subcategory_num: 3
Capabilities: 16,1
PollSettings:
If you have more info and/or suggestions of what might need tweaking, please share!
Thanks
khyizang -
You have gotten farther than most people. I managed to get the Vera to detect it for a few seconds, then it changed to a Generic IO.
You can find the jumper settings at http://www.smarthome.com/manuals/2420MqsRev2.0.pdf . (Look on the left side of the second page.) None of those jumpers should really matter to the Vera as they are all used to adjust attributes of the sensor itself.
I suspect you are running in to one of the numerous issues with the one-way nature of the Vera implementation for Insteon. (If you hook up any switch lincs you will start to find other significant issues with the implementation.) Because the 2420M sleeps except for when it is triggered, Insteon messages are only sent when it is triggered, then it goes back to sleep. Because of this, it is pretty much impossible that you would be in a situation where the events are languishing on the wire for 20-30 seconds. The only real way to introduce that kind of delay is have the message land in a queue in the Vera, and the Vera then waits to process it.
So, in a nutshell about all you can do is file a bug in Mantis and hope that MCV feels like fixing it. The only other option is to go to the pain to install the plugin that I have been working on that provides an alternate implementation of Insteon for the Vera. You can find that thread here : http://forum.micasaverde.com/index.php/topic,8910.0.html
Thanks for the info, fba
Sounds like there isn’t something simple I’ve just overlooked. For now, I’ve shifted over to getting the PogoPlug/Mochad/X10-based motion detectors going. The reception distance of the 2420 is a bit too short for most of the applications I have in mind and I don’t have enough dual band INSTEON devices to make it work.
Your INSTEON code looks great. I’m looking forward to testing it out later when I again have the need for an INSTEON solution. Do you think it would run on something like the PogoPlug that’s modified to run Archlinux? Might be an efficient way to offload some of the processing from Vera. Just a thought.
Hi khyizang,
The only thing that would prevent my code from running on a PogoPlug is knowing what CPU architecture it uses. If it ix x86 or MIPS, then there are binaries that should work already. The binaries are statically compiled, so you shouldn’t run in to versioning issues if Archlinux uses different library versions.
In general, the altsteon daemon doesn’t need much in the way of CPU time. (I designed it to run on small embedded systems as my original plan was to develop my own HA device.) It reacts to events on the wire, and every 10 minutes polls the known devices to make sure the state is correct. When a device “comes up” the initial poll time is randomized so that not all devices have their poll times come due at the same time.
So, the actual amount of CPU time you need should scale roughly linearly based on the number of devices you have. Right now, I am running the daemon on an Ubuntu Linux box separate from the Vera, so I can assure you that your offload idea would work.
Hey fba,
The unit I received was the POGO-B01 described on this page: http://archlinuxarm.org/platforms/armv6/pogoplug-provideov3 So it apparently is an ARM-based unit. Neither the x86 nor MIPS binaries will work with it. Anyway, it was just a thought. If there are binaries that will run on Vera or an x86 box, that’s probably all most folks would want.
Hi khyizang -
When you are ready to do more with Insteon, ping me. If I have the time I can see if I can get an ARM cross-compiler working. (No promises on the time though. I’ve been pretty busy.)
My experience with Insteon 2420 Motion Sensor.
Purchased 2 last year and they configured with the Vera But took some time to configure on Vera’s part. For the past year they have both worked flawlessly!! (except for the fact that triggered vs. not triggered were backwards)
Last month I decided to add 2 new sensors, both insteon.
I purchased 2 off of amazon.
When I went to add the new sensors, they both added correctly and I moved on with my day until I realized both sensors were tripped (green man) and would not reset.
After countless hours with adding, deleting, and re-adding. I realized that the only difference in the settings between non-working and working was the tripped variable.
I then realized that the model numbers were different old was 2420 new is 2842.
After talking with Micasaverde and Insteon I was out of luck except to hunt down the old 2420.
I found on Home Depots was website but unfortunatly website was outdated and received 2842.
I then tried bestbuy but again received 2842, I also was able to find a 2420 on ebay at same time. NOw to the mystery.
I set up the 2420 and it tripped correctly but later on noticed that after it tripped it flashed for 20 seconds but at the time happy that it worked.
I then decided to give the bestbuy 2842’s a second go. Son of a gun they worked!! But then realized that they too were flashing after being tripped. This bugged me so I went through and added them all again, and removed about 20 times including resetting the modem. I then tried to methodically add the new ones first but now they cant be configured at all. I gave up on the 2842 and decided to be happy with the 3 2420’s (2 old and 1 new to me).
Next I added the 2 old ones first and they worked then the new 2420 but it would not trip. back to adding and re-adding. I finally got the new one randomly to work correctly so I then added both old ones. Score!! or so I though, one of the old ones I added last was configured correctly but not tripping ( it was stuck in the red man) and also blinked many times after motion detected.
I have since deleted the last one and added/configured multiple times and currently will not configure correctly with the trip variable. It is acting like the newer 2842.
After 6 newer motion detectors I am still stuck with only 2 working but continue to be persistent and at the very least am trying to find a reason for the inconsistancy!