Bravo, fantastic way to not go to Google cache, but believe me not a way to deal with negative comments & quality related requests.
Hope at least you'll fix your product (a support guy told so) as it has its great potential and I love it by now (tbh wouldn't move from ST if they didnt FUBAR ruin their product).
To summarize from the post you deleted:
Fix zWave implementation seems lots of users complain. (Unstable, persistent hard to remove ghost nodes, etc)
Fix Mobile Geo-fencing (it's working great on ST, so it's not iOS issue)
Post your system device handlers to community to learn, adopt, advance fast. (the excuse was it will create you more support incidents to handle, but as you may not support user created drivers so not a legit reason.)
Give users ability to write own tiles (no reason given by now why is missing, but that will help in "compacting" dashboards especially using from mobile)
Would add - better handle planned, perhaps a separate section with what and when is planned.
PS: Hope you'll not again delete post rather than seriously to look into request (deleting itself speaks a lot though!) I & some other users in the post put their time and efforts to write down helping you to improve your products so respect that, do you really need only comments that it's great and all is fine??! Don't fell in this trap.
BTW currently I investigate possible zWave instability reason that many users like me might experience:
As we moved from ST, the hub is still active so I've just disabled the ST zWave antenna. Will see how it goes in terms of stability, if someone from support can advise whether it could be a viable reason would be great.
It's like Hubitat zWave - works for some and not for others
rude joke aside, will keep you posted re my findings with possible interference with ST zWave antenna (now turned off, but too early to gather some results so will advise after couple of days).
It’s posts like this one that cause people to start blocking you from their feeds. My impression is that you are more interested in complaining about the situation than you are in fixing it. Like I said in your other thread, until you get rid of all of the ghosts your zwave mesh will be unstable. Do that, and if you still have issues, then maybe someone can help you. Until then...
Thx, so far only 1 devices dropped though a bit in a distance so might be just a signal prob.
Let see in next couple of days how it goes and will advise you, so if that is the/a reason to include to other users response.
It should probably be included in the "very unlikely things to consider".
That said, many of us on here run multiple zwave networks with no issues (I have 6 zwave + 2 LoRa right now in my house all on the same frequency). So it "usually" is not a problem. But "can" it be - sure... Technically.
Definitely not the 1st thing I would recommend someone looking into, but for the lay man removing ANY variables form the troubleshooting is a good idea.
Not necessarily .. If some devices weren't removed all the way, and they were of the "poll" type it could create a massive amount of traffic as these would result in explorer frames, and ST had an aggressive poll interval.
No argument there. Although the counter to that is that devices send out explorer frame from the device side whether the old hub is powered up or not... I agree a hub errantly polling devices that can't respond can be an issue though.
I'm not saying it CAN'T be an issue, just that it usually isn't. And I agree removing variables is a good idea in any troubleshooting - so powering down old hubs, and factory resetting end devices before pairing is prudent advice if there is any question on the status of the pairing.
(OT alert) In the US LoRa CAN stomp right over Zwave 908.42MHz band - depends on which bands are being used.
You are right, though, that is usually doesn't in practice as most people use default band ranges (the consumer space is almost always either 0-7+64 or 8-15+65) that do NOT overlap with 908MHz.
So ignore my LoRa comments - you're right, that doesn't conflict in my install.
.
