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
I would love to see @mike.maxwell change the Child DNIs to not depend on the HBFC Parent’s DNI. Using the some other unique key for each child’s DNI would prevent the issue noted above. The parent’s DNI could change when re-paired (I.e. device jumps back into the original parent device), but the children would remain unaffected.
1 Like
This "may" not be possible. I remember having a similar discussion with raj via PM in ST (he handled the child component documentation for ST). Apparently the link between child and parent was made at creation and any messing with the DNI's would break that link.
If there is a solution, I believe it would lie in not changing the parent DNI to begin with. Hopefully I'm completely off base but we will wait for @mike.maxwell response....maybe this is a question for @chuck.schwer as well.
It's just a bad implementation of the child dni, there's no reason for it to be a zigbee id.
There also isn't a particularly easy way to fix it for existing installs.
I can update the driver to fix new installs, and or new new child device creation.
8 Likes
Muchas Gracias!!
Thanks Mike! That would be awesome!
Not to push our luck here but...any thoughts on the changeLevel() issue a few posts up? I get the occasional PM about this as well. Some folks seem to think the driver in this thread and the built in one are the same. 
