I'm migrating from Smarthub to Hubitat because of lack of Zwave support. I have been using Envisalink to integrate my motion sensors on my Vista 20-P system and control lights, etc. so they 'follow' me through the house.
One issue that I ran into early on with the original Smartthings was that when you arm the Vista system it only reports on sensors that will cause an alarm. If you have interior motion sensors, say on the 2nd or 3rd floor, that you still want to control lights when the system is armed, they will stop reporting.
The work-around is to put sensors that you want constantly monitoring into a separate zone that is never armed so that those devices will always report.
With the Envisalink integration, it toggles between reporting zones - reporting all zones in zone 1 and their state and then all zones in zone 2. It does this every 5 or so seconds. If you watch motion sensor in Zone 1 and it is active, it will report active then 5 seconds later, inactive, even if it is still active. It will do similar things with the armed state of the system, making it difficult if you do simple tests of 'armed', because 'armed' will toggle to 'disarmed' in 5 seconds.
The logic to make rules work is to test for the condition that will be valid over multiple polls and not trigger a rule unless it's NOT that condition. (i.e. if security-system IS NOT disarmed for 12 seconds THEN trigger the rule.) If you test for an 'armed' to 'disarmed' trigger it will toggle with every poll if your main partition is 'armed' and any other partition is disarmed.
Originally I wrote a rule that said if a contact sensor 'changed' then it was to turn on/off a fan. Using this logic BREAKS with the system because the contact sensor (in zone 1) was reported active but 5 seconds later (in zone 2) it was reported as inactive. The fan kept toggling on and off until I figured this out.
Has any thought been given to fixing the integration to avoid this type of flailing behavior in multi-partitioned systems? I.e. if a sensor is in partition 1, only report it on a partition 1 scan with it's accurate value, not reporting it with a default value when partition 2 is scanned?
