OK, so I got this V1 Iris keyfob, added it without issue to my devices, HE correctly detects if it is present or not. I also setup a rule so that if the system is set to AWAY, and the key fob is detected, the system should DISARM. I haven't tested this yet, but my question is that while the key fob is present, how come when I set the system to AWAY it stays set as AWAY? Shouldn't the system detect the key fob and disarm itself right away? Or does the system remain as AWAY because the key fob was detected as "present" when it was ARMED? If this is the case, it would be awesome, but if it isn't something is wrong, right? Can someone let me know if this is how the system is supposed to work? Thanks.
It changes states on presence changes so it would need to leave and come back to make it disarm. This allows you to arm your system at night while you are home, it's the same with Geofence presence sensors. Although with Life 360 if you hit the Life 360 refresh button it creates then I believe it will reevaluate as if it was a presence change. You could probably take the battery out for 10 minutes to see if that emulates away or not (I haven't tried), and put the battery back in to verify it disarms the system.
This was a brilliant suggestion! It works as it should but ONLY if I remove the restriction of "only when mode is" which I have set to AWAY. If I enable the rule to work only when mode is set to AWAY, then the "Keyfob present" in the Rules section does not display "True" or "False"; it's just blank. I tried removing the battery of the key fob, setting the system to AWAY, then reinserting the batteries after a few minutes and the system remains ARMED. If I remove the restriction of "only when mode is" AWAY, then the key fob is correctly displayed as present "True" in the rule section, and reinserting the batteries immediately disarms the system, whether it set to AWAY or PARTIAL. What am I doing wrong? Why is adding the restriction in the Rule prevent the key fob presence from disarming the system? Anyone knows? Thanks!
Here is what I do for presence:
I use the Mode Manager app for presence to change the mode from home to away and back to home depending on whether we are away or home.
In the HSM app, I have it set up to arm when the mode becomes "away" and disarm when the mode becomes "home." If one of us is home, then presence remains "home." If both of us are away, the mode becomes "away." If one of us returns home, the mode becomes "home." Both the Mode Manager and the HSM apps work together to make this happen. The buttons on the keyfob can be configured to manually arm and disarm, but the mode changes are automatic as is arming and disarming if you just leave and return.
The V1 keyfob does have a longer timeout than the V2 Smart Fob. You would need to consider the timeout length if you are testing.
Another excellent suggestion. Unfortunately, you are absolutely right about the timeout issue. Since it takes 3 minutes at minimum before it registers a change, it makes it useless as a presence to deactivate the system unless one sets the delay before triggering the alarm to more than 3 minutes (correct?). I tested this today by setting the alarm to AWAY and then coming back home after 15 minutes. I was checking the dashboard all the time and refreshing but no, the key fob kept registering as "not present" (my alarm delay is 40 seconds). Do you know how much shorter is the smart key fob? Could it be used to deactivate your alarm upon being present if your alarm delay is 40 seconds?
You always have the option of using one of the buttons to disarm when you get home. I found though that the timeout seems to apply more for when it was departing than when it was arriving. It seemed to be faster when arriving (or, I was slow enough getting to the door that it seemed faster).
The way it was explained to me when I was using them with Iris is that the fob tries to communicate more frequently than 3 minutes but it takes more than one failed attempt before the (iris) hub acknowledged it was gone. That cut down on the false alarms. I am currently only using the V2 smart fobs but may connect one of the V1 fobs as my wife prefers them to the V2 smart fobs. If that is the case, it will be connected to the second Hubitat that is connected with all my other Iris V1 devices. My system is much more stable with the Iris V1 devices on a separate hub from all my other devices.
Is it something to do with Restrictions being processed first ??
I'm pretty sure I read that somewhere
I just tried connecting one of my V1 key fobs. I could get it connected just fine. I am using Hub Link/Link to Hub to let the two hubs communicate. I set up the Link to Hub app to share the V1 Key Fob. I could see it on the controller hub just fine and I could configure my Mode Manager to add it for Presence to change modes like the Smart Fobs.
What I could not do was configure it as a button device. I could not see it in the button device drop-down list. That would mean that while it would work as a presence device, it can not currently be used as a button device for arming/disarming the HSM. That would not be acceptable so the V1 key fob is currently back to being removed from service.
Edit: I uninstalled it, reinstalled it and reconfigured it. I then chose to link it as a button device. The buttons work this way, but I lost the presence function. It seems like it will work as a button device or a presence device, but not as both. I don't know why. Perhaps that is part of it being a virtual device instead of a physical device on the hub where I am configuring the presence and button apps. @mike.maxwell
Yeah, I never considered using it to turn on and off the system because if I have to go dig into my bag for it (would be too worried it would get lost if I lost my keys, which have those plastic tags for pharmacies that could potentially disclose my address) I might as well just use my phone to deactivate the alarm. It was all about the convenience of having the system turn off by itself as I approach the house.
Sounds like this is what is happening, though I still don't get why after checking the restrictions first it still does not show its status (present/not present) in the rule panel. I guess it doesn't matter since the presence timeout makes them useless to turn off the alarm anyway.
That's correct, there isn't a virtual driver that includes both presence and button.
Okay. Now that I know that, I will stick with the V2 Smart Fobs and leave the V1 fobs stashed away until I need one for some guests later this year.
I did some quick testing with my phone's stopwatch function and a V1 Key Fob. Testing was done with the Virtual Presence Sensor on my control hub. The fob is paired to the hub where I have all my V1 devices. Testing started when I removed the battery and ended when I saw it change states. The second test was started when I inserted the battery and ended when I saw it change states.
Time to go from Present to Not Present: 2 minutes and 8 seconds.
Time to go from Not Present to Present: about 7 seconds.
That is in accordance with how I saw the same key fob operate on the Iris hub. Slow to depart, fast to return.
I think my wife would be just as happy having it as presence only as I don't think she used the buttons much anyway. For me though, I would like to have the buttons function also if possible. I don't see a way to set up a second instance of the fob in the linking app so the presence and the buttons could both be functional. Perhaps that would be an idea to explore.
If I can replicate your setup it would be awesome since it would allow me to use the key fob as I wanted to. I selected a virtual presence device, but I'm stuck at the device network id. No matter what I enter I keep getting this:
"The value entered for device network id could cause issues with pairing Z-Wave or Zigbee devices. We recommended that you prefix any non Z-Wave or Zigbee device network id's with a unique value to avoid this potential collision. Are you sure you want to save this device?"
Anyone know what I am doing wrong? I already checked and none of the combinations I tried is being used by any other device (also using only 4 digit/letter combos).
BTW, "control hub" meaning something other than the HE hub?
I have two Hubitat hubs, one C4 and one C5. The C4 is the control hub and the C5 is the (for lack of remembering the right term) the slave hub. All of my Iris V1 devices are connected to the C5 hub. The rest of my devices are connected to the C4 hub. I am using the "Hub Link" app on the control hub (C4) and the "Link to Hub" app on the slave (C5) hub. The Iris V1 devices are entered into the appropriate category in the "Link to Hub" app, which creates a virtual device on the control hub. My apps (Simple Lighting, Button Controller, HSM, etc.) apps are all run from the control hub. Link to Hub is the only app running on the slave hub.
I understand that if you have a Hue Bridge, Sylvania/Osram Lightify hub, or other compatible hub, that can be used but Idon't have any of those so I can address how to hook them up.
Now, for the V1 key fob, on the slave hub it is identified as Iris V1 Key Fob and has a Zigbee ID and Device Network ID of four digits. On the Control Hub, it is identified as Virtual Presence and the Zigbee ID is blank. The Device Network ID is showing a long string that ends with the same four digits. I did not have to enter a network ID. It was put there automatically.
Do you have more than one hub? If so, are you using the Hub Link/Link to Hub apps? If not, is it paired to the hub and recognized as an Iris V1 Key Fob? You should not need to edit the Device Network ID. As I stated, I am using the Mode Manager app to change modes (away/home) based on presence. In the HSM app, it is set to arm when the mode changes to "Away: and disarm when the mode changes to "Home." I do not have any Rule Machine rules set up as the other built-in apps have been sufficient for my setup which has been rock-solid since I set up the second hub for my Iris V1 devices.
I only have 1 hub, the latest version (C5, correct?). I had previously added the V1 key fob which got recognized as such without any issues. Only problem was the long timeout before it is detected as present, which makes it useless to set it up with a rule to deactivate the alarm. When I read your post about using a virtual presence device and that it allowed the key fob to be detected from not present to present in 7 seconds, I wanted to try and see if I could use it this way, but it will not let me add the virtual presence device without entering a device network id. I am supposed to enter the zigbee ID for the key fob in the zigbee Id field of this virtual presence device, correct? Leaving the network ID blank will not let me add the virtual presence device. Do I need to delete the rule I had created previously? If I can get the key fob to be detected as present from not present in 7 seconds then I would use your USM mode setup to deactivate the alarm (at least that's the plan).
The only way to have it as a virtual device is to have it connected to a second hub. The reason I got a second hub was that I was having system stability problems with the Iris V2 devices when everything was on the same hub. That is why all my V1 devices are on a second hub and I can use the virtual device. It won't work for you because it is already an actual device on the hub. You would be much better off if you can find an Iris V2 Smart Fob, but those are scarce and expensive now. I am not sure what other presence fobs work. You could search the forum for what others have found.
Edit: Also, for the virtual key fob to be detected, the physical key fob has to be detected. The virtual one does not do anything but echo what the physical key fob is doing.
When the Hubitat smart phone app is released, it will become moot as you will then be able to use your phone as a presence device.
I see. Thanks for the tip, as it saves me the trouble of trying to figure this out. Re the app, I didn't know there were plans to fix the presence timeout issue with using the iPhone as a presence device. I did try using it this way but like others have reported it loses connection after a while. Hopefully this will be resolved with the app (or with an updated driver of something) at some point. Really grateful for all your help!
As far as I know, the iPhone and Android apps have not yet been released. Since we have Android phones, I wouldn't know about iOS apps so I can't offer any advice. Hopefully, you will find something that works for you soon.