Just finished migration from Perceptive Automation IndigoDomo - whew!

Thanks everyone (especially @bobbyD) for being there during migration.

The one thing I think IndigoDomo has that beats Hubitat so far? The ability to move it close to unmovable things (like door locks) to finish the requirement exchange of keys by simply unplugging the Aeotec Z-Stick, pressing the button to include and walking to the stationary device. I solved this by putting a REALLY (50ft) long ethernet cable on Hubitat and using a USB power brick to power it...then putting Hubitat within a couple of feet of the locks (in my case three locks) to sync the required keys. Otherwise the lock couldn't get added (Yale Assure).

BUT I love the idea of this small box running my Zigbee and Z-Wave networks. I didn't have Zigbee before (except for Hue) and now I would not hesitate to go that direction if something I wanted was only Zigbee... Before I couldn't cos IndigoDomo was Z-Wave/Insteon only.

So, thanks all!

For the price of two years' subscription to IndigoDomo, I got a piece of hardware that doesn't require my iMac running all day and a Aeotec sticking out of the usb port in the back. (I always hated that rainbow flashing led you couldn't turn off.)

Thanks!

Jann

2 Likes

For future you can use a wifi dongle with it and a battery pack if you have one... to move it around

1 Like

a couple of things.. Aeon released an exe that would turn off the rainbow. I never used it, but remember seeing it. The choice between rainbow and nothing wasn't appealing, so I stuck with rainbow.

There's reason to be worried that you had to move the hub to Include your Yale locks. I have two and they have been included and excluded at least 5 times without having to move a hub. (I got an additional hub and so I moved the Locks from A to B then back to A. Repeat 3 times because I couldn't decide right away where the new hub needed to physically reside.. :slight_smile: )

Locks are "special" in three ways, 1) they are barrier devices.. and as such require encryption (aka Security) 2) vintage makes a difference. There was a time when barrier devices went to a very very low power output (whisper) during the Include. This was to prevent snooping from someone out on the street. It's fallen out of favor and new versions of locks don't do this. 3) They are battery devices and worse, battery devices with a motor. And worse yet, a motor that has a good likelihood of being positioned poorly and causing a jam meaning a high current event. In order to sell, they need to be able to say the batteries last a long time. Therefore a huge effort went into creating a special method to prevent the Z-radio from eating batteries. The motor might need to operate 10 times a day but the radio will need to be alive thousands of times a day in order to hear a lock or unlock command. The result is a set of features built into most AC powered devices called "Beaming" It's a feature that allows the Hub to assign an AC powered device to be a helper to a lock. When the Lock wakes up, it wants to know if the hub has any commands... but it will not remain listening for long. That's where the beaming device gets involved. IF the lock wakes up, the query to the hub goes through the beaming device and the beaming device answers YES if it knows the hub has a command. The Lock then stays awake a little longer to complete the conversation with the hub.

Moving the Hub closer for Includes but normal locking and unlocking work fine at a distance probably means the vintage of Lock is from the Whisper Age.

If the Lock works properly over a short distance but not over a long one, could mean the closest beaming repeater is also too far.

So I have several (3) GE/Jasco 46201 switches - which I don't think support beaming. Also 3 Aeotec ZE096 Beaming-capable outlet plugs. I also have 3 plugged in Aeotec Multisensor 6's (which I believe support security/beaming according to Aeotec's docs) BUT Hubitat didn't pair ANY of them with security. For instance one of my ZW096's has this as data:

* deviceType: **259**
* inClusters: **0x5E,0x25,0x26,0x33,0x70,0x27,0x32,0x81,0x85,0x59,0x72,0x86,0x7A,0x73**
* zwNodeInfo: **D3 9C 00 04 10 01 5E 25 26 33 70 27 32 81 85 5C 59 72 86 7A 73 EF 5A 82 68 23**
* outClusters: **0x5A,0x82**
* deviceId: **96**
* manufacturer: **134**

How can I get these to pair w/security. What's more important, I have rules for most of these. If I unpair and re-pair these do the rules go away? W/IndigoDomo I was simply able to click "resync" and it would pick up the security correctly - leaving the rules intact and just replacing the device.

Thanks in advance!

Jann

Beamer's don't need to use security itself.

The MultiSensor6's won't repeat when the battery is in use.

The multisensor 6's are all plugged in. The ZW096's are - of course - plugged in. BOTH claim to support beaming.

That simply means the Hub can choose to nominate it.. If you look at the Routing to the lock on the Zwave Details page, you should find the last hop is the one the hub would nominate.

ps: Thanks for all the help!

Okay, just looked at Z-wave details page.

BUT UMMM! I just downloaded and applied 2.3.2.131 (available today, I guess) and even though I have devices in the Devices and Rooms sections AND they respond to commands, the Z-Wave Details section table is EMPTY!

Is this important? Will it fix itself? Can I revert to 2.3.2.130???

ps: Zigbee table is NOT empty!

Okay, I just clicked reboot and the system came back up and rebooted showing me all my devices in the Z-Wave details section.

Whew! That panicked me! Maybe @bravenel should put a note that this could happen! Cos it certainly did with mine...and I am VERY careful about these things. (Developer here)

Best is to shut down, unplug power (at the wall not the hub) for 5 mins then power back up. Sometimes this does happen with an update.

1 Like

MAYBE - for us NEW users who HAVE to do the update - no option not to do it... we get TOLD we shut it down and reboot. Just sayin'

LOVE this product... but maybe make it a BIT easier.

Hey Welcome to the community!

1 Like