Additional contact methods for customer support

Hi folks,

I opened a ticket with Hubitat CS almost a week ago for an ongoing issue I'm having. Other than a robo-response I've heard nothing.

The response indicates that one can add updates "above this line." When I do, I get another email saying "sorry, our system doesn't understand replies," so no way to communicate.

Are there any other ways to get some update on this issue since there is no phone number and only the one support email that doesn't seem to be getting any traction?

Any suggestions welcome as this issue has been ongoing for months.

Thanks for any suggestions.



1 Like

Feel free to post your problem here, too. There may be someone here that can help you resolve it. Though maybe you should start a new post with a title that is more description of the problem you need help resolving.


I have posted it here and gotten some good suggestions that have made things somewhat better. But the thread went cold, so I think that all you kind folks were out of ideas for how to help this...and it really seems that it should be working better. For reference, here;s the old thread:

Thanks again to all the great folks here for shared wisdom.


Oh yeah. I remember the whole house fan RFI discussion. And yes I do believe we all ran out of ideas!

And it wasn't the house fan after all, That seemed a red herring. The inconsistent behavior is independent of that and not correlated with anything I can think of. Sometimes the indicator just fails to respond to the app commend to turn on/off.

I even added a second indicator using a plug that had been used (with 100% reliability) for holiday lights. These both trigger together from the same app. And they are always 100% in sync. When it works, both work. When it fails, both fail. so really rules out the plug for the indicator.

I'm hoping that the Hubitat folks with access to the innards may have further suggestions.

I have to imagine it's supposed to work more reliably than this, especially as other rules seem to.


1 Like

Thanks for reaching out. As mentioned on last week's ticket, your case has been referred to our Z-Wave specialists for further research. While your case is under review, we do not provide updates, unless additional details about your specific environment are needed, or our engineers have additional information that may help resolve your case.

With that being said, we have seen several reports related to "flakiness " experienced by some users who have Leviton devices. While we were unable to reproduce these issues in our environments, the "10 to 15% flakiness" that you have observed, may likely be related to the mix of devices that you have in your Z-Wave mesh, which our engineers will not be able to resolve. If the problem reported can be remedied, the fix will be released in a future update. If we hear back from our engineers, we will be sure to send you an update as soon as possible.

1 Like

Thanks @bobbyD . While the first device is a Leviton, the second device I am using is a Minoston. And they both behave identically. Inasmuch as that one worked 100% reliably, and I can control the Leviton switch on its own 100% reliably, I would think that the device mix is an unlikely cause.

I'm also not exactly what that means. Doesn't seem likely to me that some devices would actually hinder the operation of others on commands sent by the Hub, and that the failing device would be one with a direct 100 kbs connection to the Hub while the far-away, multi-hop device (also Leviton) works very reliably.

Definitely appreciate that the Z-Wave engineers are looking into this and looking forward to any suggestions from them on how to make this work as expected.


@brp It has been a while since you last posted about this. Could you give us an updated screenshot of your current Zwave details page, or even better yet use the community based Hubitat Z-Wave Mesh Details app and screenshot that. Maybe there is something we can see that you could do or change to improve things.

Also, you posted a screenshot of a rule that was not working correctly in that other thread. Is that still the one you are having trouble with? Did you try rebuilding in a different app, like Rule Machine, for example? (maybe I missed that in the other thread somewhere?)


Here's what I've got. One note: I just (like minutes ago) added a Jasco Dimmer plug that I happened to have in the same outlet as the Leviton to use this as a non-Leviton experiment. So this one doesn't have much in the way of stats yet.

So, including the repeater list, device states from Mesh tool. Also including the Simple Rule to turn on a couple of lights when the circulator goes on (note that circulator has relatively poor connection but it's the thing that works) and then turn the light off when it turns off.

There's also a simple timer to turn on the circulator on weekday mornings. That is also quite reliable, so not including it. Just the indicator-light following that is questionable.



Your first screenshot is cut off on the right side, could we see the other four columns (route count, neighbor count, etc) please?


To me, with those low RSSI, and the multiple route changes, and the lack of neighbors, you have a basic lack of strong mesh. Apparently direct routing isn't good enough in this situation. I would be curious to see these mapped on a basic floorplan. I suspect you need a repeater between the hub and 0x07, and/or 0x08, and/or 0x0A. Maybe one repeater would suffice for all 3 of those depending upon location of these relative to the hub?

Maybe even move the hub somewhere else, turn it sideways (on edge) or upside down and see if these signals get better.

I like the Ring Range extenders as repeaters, they are fairly inexpensive, and with a plug-in device like this you can move it around to find an optimal place in your mesh.

1 Like

Also, thanks @tony.fleisher for this helpful graphic...


Thanks for the cool replies.

First some notes: Other than this circulator light, everything else in the system works just about 100%. SO this just seems odd and one-offish for the Rule interaction with the devices.

As to the mesh, it does look weak, which surprises me given the relatively short distances and purported range of Z-Wave I would not have expected this.

As per your suggestions, I've included a layout below. The Hub is actually physically between 0x07 (and now 0x17 in the same location as a test) and 0x0A. The Hub is attached to my computer in my office, but I could move it a little more out from behind some monitors.

Also, it doesn't seem to recognize 0x15 and 0x16 (both plugged-in switches) as Repeaters. Maybe they're just not repeating for anyone?

The mesh is definitely weak. It should be concern that one device (0x10) serves as a repeater for 5 devices! And the range of z-wave is in open air, under optimal conditions.

You should consider positioning your hub more centrally, and unimpeded by surrounding metal.

1 Like

Thanks. I do want the Hub in the room with the computer so that I can connect via USB for direct Hub access. But I have moved it within the room more out in the open.

I see your point about the 0x10 repeater. I guess I don't see why that's the case. For example, I would expect that 0x07 would be a more suitable repeater for 0808. Not sure why it was not "chosen."

Similarly, for 0x0B, 0x0A is much better located between the Hub and target.

So it's not clear to me just why 0x10 is serving in all these cases given physical location and what I can do to have it choose other Repeaters. Doesn't seem that moving the Hub would remedy this.

Overall, not much metal around. Especially now that Hub is better located within the office.

And I realize that Z-Wave specs are idealized. But the distances here are a pretty small fraction of those so even some non-conducting walls should not impact by an order of magnitude or so, one would think.



There is no "direct" Hub access via USB. Everything is via your LAN.

However, your statement raises a question - are you powering your hub through the computer's USB port? This may not be a good idea. USB 2 ports are limited 0.5A at 5V, while USB 3 and 3.1 ports are limited to 0.9A at 5V. Both of which are insufficient to power the hub, which requires 1A at 5V - the specs of the included power adapter.

I have known at least one hub (belonged to a friend) which died after being powered from an RPi USB port for an extended period.

If you are connecting to your PC intermittently via the microUSB port (and using local networking on the PC), I should point out that repeated use of the microUSB power port is not recommended.

Edit: If the hub is indeed under-powered, it may explain some of the observed z-wave issues.

1 Like

OK, yes, I am confusing the issue here (what I remembered and what I just saw when I moved the connections).

This is not USB-connected to the computer, despite what I said. It is properly-powered with a plug-in dongle.

What I was thinking of was the RJ45 cable connected to my multi-port router. In my memory this was USB to the computer, but it's not :slight_smile:

I presume I do need to connect this to the LAN via the cable to have access.

Sorry for such basic questions. I now realize just how much I have been assuming from initial setup. Definitely appreciate the schooling here from the community.


1 Like

Do you mean the provided power adapter?

Well, there are a limited number of WiFi dongles that are supported by the hub, if your hub is on platform 2.2.5 or higher. This provides a convenient way to locate the hub more centrally.

It does require about $15-20 worth of hardware:

  1. a USB OTG cable (about $6-7)
  2. a supported WiFi adapter (about $10-15)

Here's a link to the original announcement: