Additional contact methods for customer support

brp · February 10, 2022, 6:21pm

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.

Cheers.

bobbyD · February 10, 2022, 6:42pm

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.

brp · February 10, 2022, 7:07pm

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.

Cheers.

neonturbo · February 10, 2022, 7:33pm

@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?)

brp · February 10, 2022, 7:54pm

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.

Thanks!

Cheers.

neonturbo · February 10, 2022, 9:13pm

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

brp · February 10, 2022, 9:55pm

Oops....

neonturbo · February 11, 2022, 3:27am

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.

neonturbo · February 11, 2022, 3:32am

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

brp · February 11, 2022, 3:19pm

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?

aaiyar · February 11, 2022, 3:57pm

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.

brp · February 11, 2022, 4:10pm

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.

Cheers.

aaiyar · February 11, 2022, 4:26pm

???

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.

brp · February 11, 2022, 4:34pm

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

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.

Cheers.

aaiyar · February 11, 2022, 4:39pm

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:

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

Here's a link to the original announcement:

brp · February 11, 2022, 4:48pm

Yup. I had had it plugged into a multi-port USB power supply (plugged in, not connected to computer) for convenience. Moved to an adapter I had lying around from an iPhone as I had forgotten that the Hub came with one. Using that one now.

Thanks for the info. I may need to look into that.

Despite the network weakness, everything else in the network is functioning with very high reliability (approaching 100%), except this one activity. Things that might be expected to be less stable are not. So, I'm still going to do some experiments with devices, moving the Hub more into the open within this room and seeing if the Tech folks do find the Leviton issue (which could be relevant).

In the end, if this really continues to behave like this, a more remote Wifi connection might be the way to go.

Of course, if I did move it more centrally, it would then be further from the one failing element in the network.

Thanks for the ideas!

Cheers.

aaiyar · February 11, 2022, 4:57pm

You might also consider adding an external z-wave antenna, with the realization that doing so voids your hub's warranty. Nonetheless, many of us have found it to make a dramatic difference to our z-wave networks.

tony.fleisher · February 13, 2022, 12:34am

If i understand the issue correctly..,
you have a "circulator" (0x0F) and a rule to turn on the indicator light (0x07) and another the tree light (0x15).
The problem is that Sometimes when the circulator turns on, these lights do not turn on. Do i have that correct?

brp · February 13, 2022, 12:40am

You got it. The circulator is far away and low strength, but it works well. The others are closer and higher strength but are less reliable. And the lights always agree with one another (work together or fail together).

And, in all of these cases, not only does 0x0F turn on, but the rule that is supposed to turn on 0x07 and 0x15 trips and says that it turned them on, even in failure cases.

Based on the suggestion that Leviton may be the issue, I added a Jasco dimmer (ox17) at the same location as 0x07, moved the light there and changed the rule to turn that one on and not the Leviton.

Limited testing so far, but it's been working. Of course I need more data to be sure. And we'll see what the Hubitat folks find when they get back to me on this issue formally.

Cheers.

brp · March 16, 2022, 6:11pm

OK, fast-forward about 6 weeks. Still no reply from Hubitat. It would seem that Customer Service is not a strong suit for them, although @bobbyD's comment here about a possible cause did prove helpful. Thank goodness for the Community for help in resolving issues!

With no real justification or explanation, it does seem that the "Leviton issue" alluded to above could be the cause. I'm now using a Jasco dimmer for the indicator light (in addition to the Minoston holiday light in the living room) and it is solidly reliable.

Some oddities, though:

Units OXOA (Espresso) and 0X0F (Grundfos- far away) are both Leviton and both very reliable all along.

All of these are run by simple rules.

Espresso and Grundfos are on timer controls as well as attached to switch buttons and all modes generally work.

Grundfos Light (the removed Leviton unit) and the new one, Light 2) are on rules triggered by state of Grundsos, and that's it. That;'s the only difference I can see, but behavior is quite different as noted in this thread.

Another interesting thing is that the network seems to reconfigure itself frequently (certainly every time I check, like every other day). Some things move from appearing optimal to sub-optimal. Not sure if the system ever "settles."

At times it makes odd "decisions." At one point Ox0F was a repeater for OX0A (diagrams are attached).

Also, I added a Repeater (OX18) as had been suggested, but it doesn't seem to participate much.

Also, turned the Hub on its side to see if that made any difference and moved it a bit on the desk. Grundfos is now 100kbps, and that was not the case before.

Anyway, some oddities here, but it seems to work. Certainly welcome any comments about these observations and definitely appreciate all the help!

Cheers.