First Days Migrating from Wink to Hubitat, Successes, Failures, and Solutions to Help Others…

🎬 Get Started Migrating to Hubitat
1

Alright, we’ll, my first day with the system and it’s been rough. Wink had such a well refined system at the end, trouble free and easy to use. Im having fun learning and using this new system, but, wish the hardware was a little more powerful and comparable to Winks Hub 2…

Here are my observations, questions, and comments after this first day. I appreciate any and all feedback and help in the process here…

So here we go…

Of course I tried to tackle Schlage locks as my first devices which I have read lots of trouble on in these forums, but, all-in-all, I am left confused. I can’t for the life of me understand the antenna range of the hub, it’s a conundrum. Here’s what I did… first, set up the hub, added aeotec range extender 7’s, the first 15 feet from the hub, the second 15 feet from that, and the third about 60 feet from that. The goal being to try to see how routes would be built and if the repeaters would even work… the first LOCK is 6 feet from the hub. That added just fine. The second is 6 feet away from the last repeater, or about 90 feet from the hub. Would not add. I tried removing the repeaters and putting them back in and resetting the network five times sometimes with security and sometimes without, having no idea how s0, s1, s2, etc. and no security works on these repeaters. And yet. Adding an ancient legacy gen1 vizia rf light switch at the end of the line, 90 feet from the hub, no problem… So, I assume the light switch either has an awesome antenna and power, or, utilized the repeaters successfully, while the lock was not… Lastly, I unplugged the hub and moved it to the end of the line by the other lock (as some folks said to add it this way then move it back, perhaps assuming that bigger packets sent during initialization wouldn’t be lost) and then I was able to add it no problem as long as the hub was not more than 15 feet away. BUT, then the other lock 90 feet in the other direction would no longer communicate. So, proof the locks do not use the repeaters I guess and also proof that adding a lock right next to the hub does not mean it will work after added.

And so, all of this leaves me with questions…

  1. How does s2 security work on the repeaters? If a device has a lower grade of security or none at all, will the repeater even pass the traffic if it has been set up with security? How? If a tunnel is built with the security, how does non secured data enter the tunnel? And I’d it’s insecure on either side, seems pointless to secure the middle?

  2. Zwave topology map was wierd. It basically just makes a map in order of how you add things which means if that’s the route packets are taking, it could be chaos with long gaps if you do not add things by proximity… any thoughts comments here? Also, routes were mostly empty in the column. Is that normal?

  3. Tomorrow I’m going to add some more light switches along the 90ft route, hoping they will pass information that the repeaters are missing for some reason. I might even try throwing a fourth repeater in the 90ft span to see if I can get thing running.

  4. I do have a question about fees, subscriptions, and cloud / saas services… while setting this up in my firewall I encountered a couple things which raised my eyebrows… One, this device does not play well with NAT across different subnets. Utilizing a computer to set it up with an open hole from another subnet generated page loads of sometimes 45 seconds or more. On the same subnet, 3-4 seconds max. Very odd… but Two, the bigger issue, is I watched this device communicate with multiple external WAN ips, we’ll after registration took place. Some appear to be Amazon web services… being that these external services are obviously paid for by someone for the hosting, does this not present a situation where like Wink, subscriptions and charges could be assessed to pay for those web services some day? Will the device work without these services if they were ever shut down? I haven’t tried blocking outbound traffic to these servers yet to see if it affects the operability of the device and the network but am curious if anyone knows what these external communications are for and whether the device will work normally without them.

Thanks all and hopefully tomorrow will be a better Migration Day 2…

2 Likes
2

A repeating device does not need the same or a compatible level of security to forward messages in either direction. It doesn't know whats inside a (optionally encrypted) payload, it just forwards it on. In other words, a repeater joined at no encryption will forward packets to a device joined at S2 just fine.

It can be confusing. @Tony recently explained that a device only searches for its nearest neighbors when being included or being told to so by a hub (during repair). So yeah as you include each device it will only find what was in the network before it. A good course of action may be to get the devices added/stable, then do a repair (either network wide or by clicking [repair] on each device.) Then your mesh will fill out who is nearby and get a complete picture. Afterwards your mesh diagram should look "complete." Locks are special as they include/search in a "hush" mode. I don't have zwave locks so I can't give pointers there.

3 Likes
3

Short answer is external communications are hub firmware update checks, nightly maintenance, and NTP checks.. once you get your system setup you could just block the hub from external access - you'll still want LAN access of course. The only issue you might have is time drift so using the community based NTP driver can take care of that..

Consider installing the community Hubitat Package Manager - it allows for easy management/updates of various community apps and drivers.

2 Likes
4

Thanks for your feedback. If you didn't review the following document, I strongly recommend checking it out before you move forward. Depending on how old your locks are (or your Z-Wave devices in general), they may not be able to be included via repeaters. Z-Wave introduced the support for Network Wide Inclusion with the release of Z-Wave Plus series devices, so non plus devices can only be included within the proximity of the hub.

https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Z-Wave_Mesh

5 Likes
5

This should be fine as long as they are Plus devices. non plus devices really need to be paired near the hub first.

It's not so much the antenna range. This unit is much more powerful than wink. A lot of the issues people see is caused by the fact that Hubitat has to follow the SiLabs SDK in order to maintain certification. Wink finagled a lot of stuff to work and that was not a good thing.

As to schlage, that is an issue wholly caused by schlage. Anything with pre 7,10 firmware tends to be problematic to pair. Schlage is not interested in providing anyone with firmware updates. It got so bad that Hubitat removed Schlage from their "official" compatibility list. Wink on the otherhand had a deal with schlage so they would work with them. Another issue is the whisper that has to be done for security during pairing. Schlage locks should be within a foot or 2 of the hub during pairing.

Honestly as @aaiyar repeaters don't care. That said, it's recommended that you pair all devices WITHOUT security except for Locks and Garage door stuff.

You can expand the subnet and it can communicate across subnets but hub mesh will not work across subnets. I have several subnets and don't have an issue.

This is simply for Hubitat's cloud servers and not necessary for operation of the hub. You can turn off cloud access in your dashboards and what not or block it at the firewall. The cloud access is for your Cloud dashboards (see your local ones when you're out of your network), Remote admin (subscription service but unneeded if you have a vpn) and Cloud backups (subscription service, but uneeded for general backups). Again all this can be blocked and your hub will run just fine.

Yep...

As you are doing things, please take a look at this for some rules of thumb

4 Likes
6

Worth noting that even Z-Wave Plus devices supporting Network Wide Inclusion may not support NWE (Network Wide Exclusion). So you may need to exclude them withiin range of a controller even if they include in-place. I posted on this a while back
The solution for general pairing problems with zwave for people migrating from Smartthings - #4 by Tony ; the short version is that as recently as 2018, NWE wasn't supported (it's a feature that was added post Z-Wave Plus, which arrived way back in 2014).

Silicon Labs' Installation Guide in 2018 read "Z-Wave does currently not support network wide exclusion of devices so when excluding a nodes from the network that are out of range of the gateway another exclusion strategy must be used."

They helpfully outlined the strategy: "Devices out of direct range will need to be moved into direct range of the gateway or the gateway will need ot be moved in order to exclude nodes out of direct range with this method."

Even if your devices are all Z-Wave Plus but they're several years old you can't count on them supporting Network Wide Inclusion, either. That feature wasn't initially part of the Z-Wave Plus feature set but added later (most devices post version 4.5X support NWI, confusingly version 5.x devices do not). The "Z-Wave Plus Guide" copyrighted 2014-2018 linked on z-wavealliance.org has this advice:

"Adding a Z-Wave Device
The gateway must be no more than 12 feet from a lamp module or 5 feet from a thermostat or door lock during installation. You can move the Z-Wave devices to their permanent locations after installation is complete"

It takes way too much digging to find out what Z-Wave features are supported by an older device; you can find the Z-Wave version on z-wavealliance.org's catalog of certified products but then you need to troll through SiLabs' Application Programmers vx.xx.xx User's Guides to ferret out the specifics, and many of the document links appear to be dead. If you're having problems including or excluding a device more than a few years old, its easier to just assume that it needs to be done within range of the hub.

Edit: follow that up with a Z-wave repair when that newly added device is moved to it's new location... It will be necessary if that device doesn't support explorer frames.

6 Likes
7

I have an old Z-Wave Schlage lock, BE469 I got in 2016. I've connected it to both SmartThings and Hubitat hub and it's stayed connected and run w/out issues for the last 7 years.

I believe that is part of your problem, doing the lock first.

Try the following:

  1. Pair the lock last, after you've built a strong Z-Wave mesh, including beaming repeaters like Z-Wave switches near the lock. You don't rely on those repeaters for initial pairing, but you want them there/available as soon as the lock is paired.
  2. Make sure to do a full exclude/reset on the lock before trying to pair
  3. Put the hub w/in a few feet of the lock for initial pairng - lock pairing is different than pairing other devices and wants the hub to be just a few feet away for security reasons. I used a long Ethernet cord to get the hub next to my lock.

Try the steps below, after you have set up your other Z-Wave devices. This process is very "belt and suspenders" approach, worked for me on ST and HE:

  1. Exclude the lock from the the network: Extend bolt, press Schlage button, enter 6 digit programming code, then press 0
  2. Factory reset the lock: Unplug battery, hold Schlage button and plug in battery
  3. Ensure all existing lock codes have been deleted from the lock itself: Schlage button->Programming code->2->enter 4 digit factory code twice
  4. Bring hub within just a few feet of the lock and pair the lock with the hub
  5. Enroll the lock in the Lock Manager app and enter user codes and confirm they are successfully transfered to the lock
5 Likes
8

First off, thanks to everyone for the help, feedback, and guidance! The community here is AMAZING and that is probably the most impressive thing for me so far now on my third day of integrating Hubitat...

On this question above though about a potential future conversion to a paid subscription type SAAS, I still have thoughts or concerns... I just don't want to end up there again...

This is my observation...

  1. I can access my HE from the WAN external to my home.
  2. BECAUSE of that, something, somewhere is being updated to report to my app, i.e. where and how to find my home device or perhaps even some of the interworkings/configurations...
  3. This could be as simple as some type of pointer/redirector such as a DYNDNS type of situation, or, some of things could actually be being pushed up to a cloud server somewhere and when I'm acting, my request is actually being forwarded from a server side application to my home HE device. I'm not exactly sure. But, in the HE app on my phone, certainly something somewhere is being hosted and paid for by somebody and generosity like that can't last forever.
  4. Now many of you folks have said I can LAN lock the device and it'll still work, which to me still means I could get WAN access via web-browser and port forwarding, an IPSEC/VPN, etc. and I do believe that in that regard you would be right that my HE couldn't be bricked if someone someday decides to turn it into a SAAS. BUT, that does still mean that the android/iphone apps would stop working if I'm correct in number 2 about something being pushed to the cloud and it requiring it for functionality.

So, what do ya'll think. Am I off base here or inaccurate in any of these observations? I'm sorry to keep sweating about this, but for once, I want to own my home tech and after Wink, I'm done with corporate fates and subscriptions on this kind of stuff.

9

Yes to your dashboad. If you want access to your admin functions you need to install a VPN or subscribe to the remote admin service. (VPN keeps it free)

Only for use of the cloud dashboard. If you setup a VPN you can simply turn off cloud dashboard access directly on the hub. Or even block the hub from exiting your network alltogether

Just the dashboard. As said above. You can set up a VPN to bypass.

Yes. But you also won't be able to get updates until you allow it to reconnect to the internet. You can do this periodically.

No, port forwarding to HE is blocked by design for security reasons.

Correct

Only for cloud, not for local or VPN and you don't even need the app to access your dashboard, there is a direct address link in each dashboard..

1 Like
10

One thing I wanted to add regarding dashboards - if you use Android devices there is, IMHO, no better Dashboard option than the community Android dashboard app. Amazing app, updated constantly by an extremely active and responsive dev who is continually implementing requests from his users. It's good enough that it could convince you to buy an Android device just to be able to use it... :slight_smile:

3 Likes
11

So, here's what I have done so far, now on day 3. Again, hoping to help any other Wink Migrator along with what I run into...

Choices and Completions...

  1. I abandoned my old locks and got new ones. My locks were Gen 1 Z-Wave, circa 2014, there was just NOTHING I could do even after following everything everyone said to get them to work with the exception of getting another hub and placing it right next to the one lock that wouldn't function too far away from the hub. Repeaters didn't matter during or after pairing, nothing. Only hub distance mattered. And so , I didn't want to wait 3 days for another hub to come in and just went to the local hardware store and got new locks. I did end up choosing WIFI locks (which I know goes against the corporate fate/subscription things I mentioned before), but here's why... First I don't think the companies behind them will go that route because they are lock manufacturers first and foremost not software makers. Next, because most of my devices are legacy z-wave and very taxing on the system because their communications are inefficient, I felt having less on the system would help and also, heaven forbid something happens to brick my Hubitat some day, having a few different maker apps working my smart home means next time, I won't lose EVERYTHING and EVERY device as I did with Wink... And, for those of you who are worried about cloud security for locks, a crow bar is about a trillion times faster than trying to hack a network so if someone wants in my house that bad, they are going to get in one way or another...
  2. I installed lots of repeaters with my one hub I have posession of and have had mixed results so far.
  3. Old Leviton lights and switches pair fairly easily which is nice. Leak sensors pair fairly well, but I've already noticed I'm going to run into another problem. Some of my sensors, leak sensors included are Zigbee. And, I don't have any zigbee repeaters.... Grr...
  4. My combo smoke/CO alarm from Kidde appears to run on an independant 433Mhz frequency that Wink had a special radio for. It was a very nice feature to be able to run all of my motions, door and window sensors, everything through wink. That's not going to happen here... Unless as I've read in some other posts in these forums, I get a system that listens for a siren and converts it to a Z-Wave signal... Eco FireFighter something or other... No thanks. I like clean setups and am not one for jerry-rigging things... I'm curious how my other sensors will work with pairing.

Observations...

  1. As I add more and more legacy z-wave devices (I'm at 35 now), the system is starting to feel more and more like Wink did 10 years ago and that's not a good thing... First handful of adds it was zippy and fast and way better than present wink, and now, it's starting to slow down a lot. Back in the day, Wink would take sometimes 5 minutes to turn a light on or off, the communication algorithms were just so badly written in concert with the inefficient methodology of legacy Z-Wave... But, somehow, around a year ago, after Lutron's patent expired, etc., Wink knocked it out of the park. I was blown away with how fast my 120+ device legacy system worked. Push a button on an app on the WAN side, and less than a quarter of a second later the light turned on. Cell phone to tower to telecom infrastructure to backbone to server, back to telecom infrastructure to your home modem to your wink to the device in a quarter of a second. It was quite simply put, AWESOME. First 10 devices on HE, was that awesome. Now at 35, It's about 2-3 seconds after turning on a light that it comes on... I AM going to run a z-wave repair when I'm all done adding things, I also know routes can take time to sort themselves out from reading other posts you all have written, and finally, I haven't even dabbled into polling yet which I'll need to because some of the states of these lights report incorrectly so I'll need to get to the bottom of that, but, having said all of that, I'm missing my winks zippiness a bit right now...
  2. Exclusion doesn't work that great. I dug out an old leviton handheld Z-wave hub to exclude devices because once I was about 45 feet away from the HE, just wasn't working anymore.
  3. Inclusions are tricky. Some devices are causing some sort of leak or loop which bricks the z-wave functionality and introduces ghosts... For example, Leviton Smart Outlets... My HE HATES them! If I add two in a row, inclusion and exclusion do nothing after the ads. I have to reboot the HE to get inclusion and exclusion to start working again. But, Leviton switches, no problem. I'm also noticing on inclusion that the further away I move from the hub, the slower the whole process goes as well as the probability of success. Even if I have two devices added right next to the new one I'm adding and two repeaters 5 feet away, it doesn't seem to matter when adding a device. I'm worried that once I get out to 70+ feet away, no matter how many repeating devices and repeaters I have, I won't be able to include anymore without another hub in close proximity. I may be forced to dig out a 150 foot extension cable and a 150 foot cat6 cable and walk around my house with my hub... I hope that's not the case as it is 2022, not 1995... We shall see... We shall also see what other types of devices on my network this system doesn't like or flat out will not communicate with.
  4. I've been digging around in the package manager a lot of you recommended I install. Thank you. Good Advice! I've added in an auto rebooter, a mesh analysis tool, and have been looking around for others. I have some questions there... I noticed there is a driver for the AeoTec Range Extender 7. I have a bunch of these but what is the driver for any why should I install it? These typically are simple devices that don't need anything but to be plugged in, so, I'm curious what the driver could be for... Any other "gotta haves" in the package manager anyone would recommend? Or non-package manager apps or drivers that are really useful?
  5. In a day or two, when I'm done adding devices, I'm curious with how automation integration is going to go... For example, water sensors shutting off valves and triggering switches and alarms while finally sending me a push notification and an email. These were all push button in Wink and I'm curious how it's going to go here. My guess is I'll be learning some sort of basic IF THEN ELSE language with some sort of third party push notification app and email app. Next, Wink used to PUSH warn me when battery levels on devices got low... The only place I see battery levels in here is in the log, on the device page, and on the dashboard. I assume I'm going to also be writing something to warn me when battery levels get low. Next, security. Motion, doors, windows, any of those triggered historically, the whole house would light up like fort knox with emphasis placed on the area where the sensor was triggered, sirens would start blaring everywhere, push notifications, emails would be sent, videos would start recording and uploading and sending, etc. Finally and simply, lighting. I imagine automating groups of lights to turn on and off at scheduled intervals will be fairly straight forward, however, what I'm not sure yet is how randomizing schedules will work. In wink, I had some things randomly come on within XX minutes of sunset and go off within XX minutes of a specified time, sunrise, etc. The randomness being a nice feature if you are ever out of town so that your home doesn't look automated to criminals... Not sure if I'm going to find built-in functionality for that, both the randomness and the tracking of sunrise and sunset based on my lat/long location, or if I'm going to have to write all of that and communicate with external databases or APIs to acquire that data.

Ok, well, I'm off to start adding more devices and see how it impacts the HE speed. I'll report back tomorrow as now I'm going to be operating in the areas 45+ feet from the hub so fingers crossed yesterday's slowdowns and hardships were anomalies!

Thank you again to all of you for your support, help, and recommendations. I'm trying to pursue as many as I can and some of them are really making a difference!

1 Like
12

@rlithgow1 , thank you, that really clears things up and everything makes sense. For now, I'll keep cloud running as I'm not afraid of it, just don't want to pay for it, so, if it ever becomes SAAS, then I'll just turn it off and go the VPN route. I appreciate the clarity, thanks!

1 Like
13

WOW! My kid has an android tablet because I didn't want to for over $$$ for them to trash an ipad so I may just download that and check it out! Honestly, the apple version is nice as well, no complaints yet, but, would love to see what a passionate dev has done in the android world...

2 Likes
14

If you're an Apple household, why not install Homebridge and use the native Apple Home app, which is available for Macs, iPhones and iPads?

This is what the Home app with my Hubitat devices looks like on my Mac. Works very well, and the Homebridge integration with Hubitat makes it seamless.

Screen Shot 2022-07-15 at 7.34.43 PM
Screen Shot 2022-07-15 at 7.34.43 PM1802×1484 196 KB

Also, keep track of this development:

3 Likes
15

Regarding your slowdown you're seeing after adding a bunch of devices, couple things:

  1. Sounds like you're watching it carefully (you mentioned noticing ghosts appearing) but keep a close eye on your Z-Wave Details page when you're doing inclusions - you should check it after each device inclusion and confirm it joined succesfully (all colunms for that device are populated, particulary the Device Class, Device, and Route columns. Any ghosts should be cleared immedately before trying to add more devices.
  2. I have seen times (on older versions of the Hub Z-Wave Firmware) where I would need to reboot the hub every two to three device inclusions. I haven't had to do any mass-inclusions in a long while, but rebooting the hub every two to three is probably a good idea if you're having inclusion issues.
  3. Your Z-Wave network is in a bit of a "Storming and Forming" phase and devices should settle down and adjust routing as they and the Z-Wave SDK see fit. TL;DR: Give it a week or more for things to settle
  4. Right now, shut down your hub from the Settings screen, then pull power (from the wall, the connector at the hub can be a little fragile) and wait a minute or two and plug the hub back in. Pulling power allows the radio to do a full restart which can help settle things in.

You should definitely not have multi-second delays in responses from the Device page or from automations...I don't have experience w/older Leviton devices, however, so I don't know if they tend to be problemmatic on this platform and may be contributing to your issues.

Progress is good!

2 Likes
16

If looking for a good VPN - checkout WireGuard

For ease of setup and use there is also TailScale which uses Wireguard (I think) and has a free tier which would be perfect for this use-case.

3 Likes
17

@danabw , WOW! As you were writing these things, I was experiencing them! One of my observations I'm becoming more and more confident in is there is some type of memory leak or operational stuck loop in the inclusion exclusion processes. I agree with you as well that it seems to perform better if I reboot after 4-5 inclusions. SO, definitely something awry there in the process. And, whatever is happening, I think can also be triggered by halting the inclusion/exclusion process. For example, if I start the inclusion and exclusion process after a fresh restart, and stop it because say I wasn't ready or had the device in the wrong state for an inclusion, and press the button again to stop the process, I will have more than likely re-created whatever is happening after 5-6 inclusions. Some sort of leak or stuck look that breaks down the whole of the z-wave infrastructure on the hub. No Z-wave related process behaves appropriately after whatever happens happens... Turning Lights on or off, running z-wave repair, nada. It all breaks down until a reboot...

I have not tried shutdown and power pulls. BUT, after reading your post here, and my experience, I am going to start trying frequent reboots as well as everything else you mention.

A final observation I have run into in the last 30 minutes (after trying z-wave repair because I was having so many problems), is that 1. The Route tables were ALL empty before z-wave repair... Three light switches and all 8 repeaters failed the z-wave repair process, and, after that process was complete, the route tables were filled in for most devices, but, missing on those 11 devices plus a handful of others. So, that was weird. to me. ALSO, the routing is UTTER chaos... Makes no sense. A device is running through another one 150 feet away, only to jump back to a device that's 5 feet from it. I truly don't understand how this routing is developed.

Is it normal I wonder for the routing tables to be blank after adding 30 items, prior to running a z-wave repair (originating with a fresh system)? And then, is it normal for all repeaters to fail the repair process?

These are my thoughts right now and yes indeed, I am in the storming and forming phase. But, for those of you migrating to HE, if it works like mine, indeed, frequent reboots/shutdowns while adding does seem to help. Hopefully once everything is added it will normalize/stabilize.

18

You definitely need to do this.

Missing routes for mains powered devices = (in majority of cases) ghosts. If a shut-down/power pull/restart doesn't help, you'll need to remove those ghost devices and pair them again. They are the source of your delays and other performance issues. No routing = no fun. :slight_smile:

You can try individual repairs on the devices w/out routing after you do the power down process, but often they will not repair. If you are offered a "Remove" button after running a Repair or Refresh on a device that lacks routing, Click the Remove button so it's removed from the hub database and you can reset and re-include the device.

Odd routing is usually OK, and not something to "mess with" unless that device is having performance issues.

3 Likes
19

Welcome to Hubitat! I came from Wink too.. in more ways than one. I used to work there on the Android app. Great and very smart people but the ownership was basically absent and stopped paying the bills. I'm surprised they're still in business (and that you lasted as long as you did).

I switched over a few years ago and while it took me some time to get all of my devices setup, I'm more than happy with Hubitat. It is all about the community drivers and support. While Wink worked great with some devices - Hubitat feels like it works with just about everything.. things I never would have thought could be added such as B-Hyve (hose), Kasa (Wifi swtiches/outlets/etc), Blink Cameras (arm/disarm).. and plenty of non-device services like the awesome GameTime app (MLB/NHL/NCAA/etc updates).. just to name a few. None of those would be remotely possible with Wink AFAIK.

  1. This could be as simple as some type of pointer/redirector such as a DYNDNS type of situation, or, some of things could actually be being pushed up to a cloud server somewhere and when I'm acting, my request is actually being forwarded from a server side application to my home HE device. I'm not exactly sure. But, in the HE app on my phone, certainly something somewhere is being hosted and paid for by somebody and generosity like that can't last forever.

Hubitat does the DDNS forwarding or whatever it's called from it's server to your Hub. I can't say for sure it'll be free forever but it's also just a simple redirect and that's it. It's not storing any data so I don't think it's super expensive to maintain. Wink on the other hand was paying a TON of $$ for things like Amazon S3 cloud storage and 3rd party services like PubNub for pushing updates to your device.

Hubitat also provides some kind of free re-direct service from Google to your Hub as well so you can control all of your devices via Google Home. I believe Home Assistant charges for this.

Yes, there's a paid service to remote admin your hub offered via Hubitat.. but if you're just looking to view and control all of your devices - it's free. Like @danabw mentioned there's the Hubitat Dashboard (not related to Hubitat.. I'm terrible at naming things!) if you have an Android tablet. But, there's lots of options to choose from and I'm sure they all have their pros and cons.

Next, Wink used to PUSH warn me when battery levels on devices got low

I have a sneaky feeling that wouldn't be too hard to setup.. I haven't done it personally though. The rule manager is a bit on the painful side of things depending on what you want to do. But, that IF ELSE logic is there.

If you just want to view all of your battery levels though, I have a tile just for that

image
image1080×2160 149 KB

Next, security. Motion, doors, windows, any of those triggered historically, the whole house would light up like fort knox with emphasis placed on the area where the sensor was triggered,

I do have this setup on my Hub.. I'm sure there's LOTS of ways to do this but here's what I'm doing:

  • first off you need to setup the native hubitat app for iOS/Android. That will create a device that you can 'push' notifications to
  • make sure you have Mode Manager setup so mode will change to 'away' if your phone(s) are away from home.. you'll want this so you don't get all kinds of alerts during the day, while you're home.
    image
    image1132×698 73.6 KB
  • lastly, add HSM (hubitat safety monitor) app and configure it how you want.. my example below sends my phone a notification when any contact or motion sensor is changed and the alert says something like " at " which leads to messages like "Front Door Opened at 5:20 PM".
    image
    image1542×1164 130 KB
5 Likes
20

@danabw , The Power Pull worked like a champ! I can turn devices on and off again, so, that's good. I'm going to go back to adding devices and see how that works...

A few more interesting things have happened after the power pull...

  1. I now only have 5 Mains missing routes after the power pull.
    I tried repair on two of them to no avail.
    Then I thought what the heck, let's try them. AND, they all work... How!? lol.

  2. I'm assuming that in light of this, my little "reboot" app that I installed from the community isn't going to work much. It has an option to only restart the z-wave instance or do a full reboot. BUT, I have rebooted multiple times and that didn't work. The power cycle you recommended is what ended up working. SO, that brings me to wonder if it is the radios that are being refreshed during a full power cycle, has anyone written an app to do this programatically on a schedule? Or, perhaps as you have pointed out, this hopefully will only be an issue until I get all of the devices added.

  3. So I started adding again. Saw multiple historical Zwave crashes in the error logs so it all adds up now, but the power off cycle worked great. I was able to add 7 devices before my next crash and it crashed on a leviton outlet which I've had trouble with in the past so I'm not sure if the leaks hit their limit or the device itself threw things off. Just did another shutdown and restart and I'm going to start on that outlet again!

1 Like