Hi there, I have a Nue Zigbee dimmer using the built-in driver (i.e. "Nue Zigbee Dimmer").
A string of errors in the logs:
dev:10312021-02-21 13:11:11.073 errorgroovy.lang.MissingMethodException: No signature of method: nueHGZBDimmer.recoveryEvent() is applicable for argument types: () values: [] (recoveryEvent)
dev:10312021-02-21 13:09:32.061 errorgroovy.lang.MissingMethodException: No signature of method: nueHGZBDimmer.ping() is applicable for argument types: () values: [] Possible solutions: find(), print(java.lang.Object), find(groovy.lang.Closure), print(java.lang.Object), print(java.io.PrintWriter), run() (ping)
dev:10312021-02-21 12:44:43.069 errorgroovy.lang.MissingMethodException: No signature of method: nueHGZBDimmer.checkEventInterval() is applicable for argument types: () values: [] (checkEventInterval)
I have reset the device many times, and re-added it to the mesh. It invariably 'falls off' the mesh at some point, requiring another reset to get it to re-join.
[edit] i have several of these devices, and the errors do happen on each of them. i thought i'd focus the issue by referring to a single device, but on second thought it would be misleading to say it only happens on one.
this being a built-in driver, i expect i'll need a hubitat person to help with this one.
hi there @mike.maxwell not had any responses at all to this. these Nue dimmers are still having issues regardless how many times i try resetting, etc.
every dimmer in the house shows these errors, i have filtered just to look at one of them (filling up my logs...).
This looks like a scheduled job that was set from a user installed driver.
The inbuilt drivers do not have nor use a method named recovery event.
You can remove this by switching to the driver Device and running the deleteAllScheduledJobs command.
aahhh..i see. i originally had a community driver installed, but when the inbuilt one came available i switched to it. i didn't realise that changing the driver does not remove the scheduled jobs associated with it...thanks will do your fix.
I'm still having issues with these Nue dimmers. They need factory reset + re-adding to mesh every few days. PITA to say the least.
it works fine for a few days, then just drops off the mesh. the mesh is strong, i have battery powered devices further away from the (quite close) repeater, and they are solid as a rock.
i have noticed that when it drops out, the Zigbee routing table shows that the route to the Dimmer is routing via the Dimmer. Which seems weird to have that entry when its a (direct) neighbor of the hub., the other neighbors don't have a similar entry. I'm not 100% sure thats an actual problem, and if so what to do about it, but it doesn't seem right...see here
Unfortunately no help in diagnosing your issue, but Route Table entries where a neighbor appears to be routing via itself are not unusual; it's normal to see those for devices that are the best single hop routes to the hub. They may be tricky to see since the Route Table Entry section isn't static and doesn't represent the complete routing table. It's more like a cache of recent route requests. Depending on the activity level in your network, the entries for a given device may age out fairly rapidly and only appear if/when the controller generates a request for a path to it.
So if the device is a neighbor and the link is strong to the hub, the best path from the hub to that neighbor will be direct (via itself and no other router) and that is what it its showing in your mesh for the 59A8 device. It has a good link to the hub (inCost/outCost both 1). In contrast device 2D61 (GndBed-IKuuDGP0USB) is also a neighbor router, but has a more marginal link to the hub (inCost 3, outCost 5). The route table entries show that when the hub talks to it, it prefers to do so via another device (Living/Stairs-STbulb) which likely shows better cost figures.
thanks Tony - do you know a way to get a complete routing table?
any other recommendations on what steps you would take to troubleshoot?
one of the challenges is that it takes days to fall off the mesh, so enabling debug logging for that period of time and finding anything useful in all the noise.
EDIT: FWIW here is some debug logging when it is working, and turning it on and then off:
AFAIK there is no provision for this. The Zigbee spec has API commands that can be used to request a specific devices's neighbor table (so in effect a 'getChildandRouteinfo' view of another Zigbee router) but these aren't available from the user interface. If you have a Zigbee sniffer, you would be able to see a complete route since it is part of the source routed frame.
Re: troubleshooting; when the issue happens, is it just the Nue devices that become unreachable? Do they all appear to fail simultaneously?
Though this may be impractical, if I were troubleshooting this without having mapped the mesh I would try operating a smaller subset of the Nue devices (just one or two) to see if I could get them to be stable. Without a map of your mesh, it may be hard to visualize but could a single problematic device (that is in the routing path) be the root of your problems with the Nue other devices?
It's odd that a reset/rejoin is required to recover; rarely I have needed to do this on my network (like during a recent lightning storm related power failure; all 3 of my reliable Cree Zigbee bulbs needed to be reset). Needing to this on a regular basis almost seems like some kind of protocol incompatibility.
Btw, I see that some Nue dimmers are advertised as supporting the ZLL profile; newer ones Zigbee 3.0. The HGZB-04D that turned up in my search shows "Wireless type: Zigbee-ZLL". If they are Zigbee 3.0 certified, they should play nice with HE.
The compatibility of ZLL and ZHA devices (Hubitat supports the ZHA 1.2 profile) seems to be the subject of some debate. AFAIK the two profiles were supposed to be compatible, at least at the network layer; in practice there have been lots of issues (a Google search will turn up quite a few).
Hi @neonturbo its possible, but i have no other issues with any other device - everything has been solid as a rock except for the Nue Dimmers.
I have about 6 Nue devices on the mesh:
4 single/double switches - seem to work OK (occasionally they don't respond to a button press which is annoying, but they never drop off the mesh)
2 dimmers - on opposite sides of the mesh, both of these drop off the mesh regularly as described.
I run Hubitat on channel 25 to avoid conflict with 2.4G Wifi on Channel 1.
I run Phillips Hue hub on channel 24: this controls about 8 RGB bulbs.
Since installing the Nue switches in my house, I have noticed that the single gang dimmers are constantly dropping of the network. I have two dimmers and they both behave the same way. Commanding the dimmer to turn of or on works however the status of switch is not reported correctly. When this dimmer drops, checking in on getChildandRouteInfo, the Age will show 7, inCost=1 but the outCost=0. Generally any child device that routes through this dimmer will also drop. Has anyone found a solution or workaround?
How many Zigbee devices do you have, in particular line powered or repeaters?
If you have metal boxes, thick walls (masonry or heavy plaster) air ducts, or other blocking materials, you could have issues.
You also should probably look at what Wifi channel you are on, and what Zigbee channel you are on. There are certain Wifi and Zigbee channels that can interfere with each other. This is a good thread outlining those channels. Zigbee Channel Overlap
