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. 
To be completely candid, I knew that wasn't the case. However, I judged that there would be a lot of eyeballs here that had more of the backstory/history of development for this device and might also be interested in any explanation/solution...
Having just gone through this yesterday when I had to rejoin one of my HB's, I'd much rather go through this once now than multiple times down the road when it happens again. Much easier to deal with when it's planned than at some random time. Thanks Mike!!!
4 Likes
Not a problem, I would've done the same. Btw, that post actually wasn't directed at you. I have received a few PM's regarding this in the past because I was heavily involved with the initial driver here and over in the ST forums. Comes with the territory. I just don't know what to say regarding the changeLevel() issue because we have never received an official response I can point to. Hence:
and
Hopefully Mike responds when he can.
1 Like
Hello,
I am a newbie to Habitat but so far it is going well. I have 2 fans with Hampton Wink enabled controls. I use the KOF Fan control driver and the 2 child device drivers. The light on and off works great in the dashboard but I can get the fan control to work in the dashboard. It does work if I go into the device itself.
I have a feeling I am doing something wrong in the configuration or in setting up the tile in the dashboard. Can you offer this newbie some advice.
Thanks,
Joe
