..but I do. Works great. 
(I don't think they're picky about what Zigbee router they go through, or at least I haven't seen any Xiaomi-like problems with it.)
1 Like
After reset, controller connected through IKEA plug. Let's see if that will make a difference.
2 Likes
I posted this in the Amazon Sylvania topic, but I'll post it here too. Interesting Reddit about Peanut vs Tradfri.
Edit: Link seems to be busted. This may work:
I very much doubt that either Tradfri or Peanut are better then Xbee pro... None of my Xiaomi sensors are dropping. Only Fan Controller is acting up.
That’s the issue. The peanuts are better only because of the reliable repeating. Both here and on ST many have tried other repeaters in hope to solve the problem. Unfortunately, only those two devices appear to work reliably.
I bought a fan controller, but haven't installed it yet. I don't have either the Peanut or the Tradfri. But I do have some of the Iris outlets. Would those suffice you think? Or should I just go with something else. How about the ST outlet, that is a zigbee repeater right?
I've been using Iris v2 outlets for over a year now and my fan controllers are rock solid (until I get into the summer and the mass power flickers/outages begin...Florida living at its finest.)
2 Likes
Thanks. I don't need to invest in others then. Maybe an Xbee just for fun though...
2 Likes
I feel your pain. I was in the same place and ready to give up, until I read the post by @JDRoberts,
and that fixed it.
Mine was dropping every other day, even with a peanut and a tradfri plug right below.
Until I moved the tradfri plug to the loft above the fan, that fixed it.
Something about the blades affecting the signal.
So if you can move your plug to the room/attic above, that should help.
PS-the included remote stinks, don't point it at the fan, hold it next to your leg, and it works much better
This is how I got the one in my kitchen to work. The repeater is in my office and is twice as far away from the hub as the fan is and that's the repeater it chooses. The on in my office, which is only one wall and 4 feet from the hub, repeats through an outlet 10 feet away through 3 walls. I've given up trying to make heads or tails of it. But hey, it works.
How do you see the path a device takes to get to the hub?
I searched the forums and this thread before posting, but I'm probably missing something that has been picked-apart and explained or solved in the past. I just installed this controller yesterday and everything is working great (I have a tradfri plug about 6 feet away).
When I call level change up/down from a button controller (or from the device page) I get these errors and no level-changing going on:
dev:609 2019-09-02 20:33:53.880 errorgroovy.lang.MissingMethodException: No signature of method: HamptonBayZigbeeFan.intTo8bitUnsignedHex() is applicable for argument types: (java.lang.Integer) values: [0] (startLevelChange)
dev:609 2019-09-02 20:33:47.429 errorgroovy.lang.MissingMethodException: No signature of method: HamptonBayZigbeeFan.intTo8bitUnsignedHex() is applicable for argument types: (java.lang.Integer) values: [1] (startLevelChange)
Am I doing something wrong? Known issue? Would appreciate any thoughts...
I don't remember if @mike.maxwell ever confirmed this, but I'm pretty sure the Hampton controller does not support the changeLevel zigbee commands.
See this thread:
Button Controller App
1 Like
Its easy to check, it would have the appropriate commands in the driver details...
IIRC, the child dimmer device has the start and stop level change commands, however they don’t actually work with the HBFC.
Seems you are correct, again.
dev:1224 2019-09-02 07:17:17.838 pm info Office Ceiling Controller light was set to 50% dev:1224 2019-09-02 07:17:10.288 pm error groovy.lang.MissingMethodException: No signature of method: HamptonBayZigbeeFan.intTo8bitUnsignedHex() is applicable for argument types: (java.lang.Integer) values: [0] (startLevelChange)
Mike, either there is an issue with this driver or you might want to remove the changeLevel options from the child devices. This pops up every so often.
1 Like
I actually see it on the parent (never really sure which child/children actions on that device get performed on, so I avoid them all...) and the light component child.
That being said, I also get a lot of java.lang.NullPointerException: Cannot invoke method sendEvent() on null object (parse) errors on the parent device when I try most child commands (happy to provide actual repeatable steps if no one has reported this before, though I think I have), despite the commands actually working (but the device attributes never updating, etc.), possibly a result of me having to re-join it so many times (generating a diffferent DNI) to keep it working. A different issue but might also be worth looking into.
That issue has been discussed a few times as well. It is caused when, as you said, the parent gets a new DNI because of a rejoin. This breaks the parent/child link between the devices. The only way to fix this is to delete and recreate the child devices with the new parent.
1 Like
