[SOLVED] Minka-Aire Dyno XL: Lost control of second fan

I have two Minka-Aire Dyno-XL fans set to different codes. I originally had them paired to a Bond Bridge and both fans worked fine. I then decided to use the included Smart by Bond chip in one of the Dyno fans (Fan A). I went through the procedure to add a “Smart by Bond” device (FAn A) in the Bond app and only saw one Smart by Bond device (Fan A). Anyway I set hat up and Fan A works fine the Bond App, but now the other fan (Fan B) that is still paired to the Bond Bridge does work at all. Even the remote does not work. Is it just a coincidence that Fan B stopped working after I started using the Smart by Bond chip in Fan A or did pairing Fan A using the Smart by Bond chip in Fan A break Fan B?

Help!

When you look at your WiFi networks available on your phone, do you see still a Bond Config KS… network? The auto detection in the Android app is not always 100% reliable.

Presumably to avoid interference in your initial install, you had changed the remote control address (DIP switches) on one of the fans, perhaps Fan B?

The only thing I can think of is, that you may have inadvertently performed a factory reset on Fan B, causing it to stop responding to Bond Bridge and the remote control.

You can re-pair the remote control by power cycling Fan B only and then holding down the power button on the Fan B remote for 10 sec. You should see the fan light flash 3 times and the remote should start working again.

Not sure how I did that, but re-pairing and it worked. Both fans are on the same circuit, so I had to disconnect Fan A by manually removing the daisy-chain hot wire in Fan B. Pain, but that is what I did the first time I paired them. Anyway … Its working now so thanks!

And the Bond App now sees the Smart by Bond chip in Fan B.

Great!

FYI: you can also re-pair via the app. Just go to device settings > Manage Remotes.

OK Thanks! I am having some problems with the AK Bond Homeseer integration and think it has to do with Alex’s implementation of the Smart By Bond chip. It appears his plugin uses the ID to distinguish between bridges and the two Minka-Aire fans I have report the same ID on their bridge. I see that there is a beta firmware update for the Smart by Bond bridge chips. Would that bring anything to the table for the AK Bond integration?

Could you double-check this? They should have similar IDs (maybe all but the last 2 or 3 numbers are the same) but having the same ID would be a big problem!

Here is what the AK Bond plugin is reporting for both fans (Sofa Fan and Dyno-XL Fan):

I am guessing he should be using the first ID (KSMWDCE75139), not the one that says ID = 1;

------ Sofa Fan -----
ID: KSMWDCE75139 IP: 192.168.0.184 Port: 80 Update: 10 sec
*** Bridge Info ***
BondBridgeInfo HSPI_AKBond.DeviceBondBridge+BondBridgeInfo
target breck-spitfire String
fw_ver v2.6.7.5 String
fw_date Mon Aug 19 14:35:53 EDT 2019 String
uptime_s 639 Int32
make Minka String
model F1001 String
branding_profile MINKA_F1001 String
bondid null
upgrade_http True Boolean
api 2 Int32
_ 15353388 String
extra null
*** Token ***
“…” “…” String
*** Device Info: Dyno XL (1) ***
1 HSPI_AKBond.DeviceBondDevice+BondDeviceInfo
ID 1 String
name Sofa Fan String
type CF String
location Great Room String
template null
actions
TurnOn, TurnOff, TogglePower, SetSpeed, IncreaseSpeed, DecreaseSpeed, TurnLightOn, TurnLightOff, ToggleLight,
SetBrightness, IncreaseBrightness, DecreaseBrightness, CycleBrightness, SetTimer, BreezeOn, BreezeOff, SetBreeze,
SetDirection, ToggleDirection,
List`1
_ ea1dedb0 String
commands null

  • 1.BondDeviceInfo.state HSPI_AKBond.DeviceBondDevice+_State
    _ 8999f793 String

1.BondDeviceInfo.properties HSPI_AKBond.DeviceBondDevice+_Properties
_ 95fedcf4 String
*** Device Properties: Dyno XL (1) ***
1 Dictionary2[String,Object] (Lenght 5) max_speed 6 Int64 breeze_max_speed 6 Int64 breeze_min_speed 1 Int64 breeze_period 30 Int64 _ 95fedcf4 String *** Device State: Dyno XL (1) *** 1 Dictionary2[String,Object] (Lenght 9)
power 0 Int64
speed 1 Int64
light 0 Int64
brightness 100 Int64
brightness_cycle_phase -1 Int64
timer 0 Int64
breeze 0, 50, 50, JsonArray
direction 1 Int64
_ 8999f793 String
*** Device Commands: Dyno XL (1) ***
1.Commands Dictionary`2[String,Object] (Lenght 0)

------ “Dyno XL” Fan ------

Here is what the AK Bond plug is reporting for the two fans:
‘KSMWDCE75366.Bridge’ (Bond Bridge) - Device Configuration
ID: KSMWDCE75366 IP: 192.168.0.129 Port: 80 Update: 10 sec
*** Bridge Info ***
BondBridgeInfo HSPI_AKBond.DeviceBondBridge+BondBridgeInfo
target breck-spitfire String
fw_ver v2.6.7.5 String
fw_date Mon Aug 19 14:35:53 EDT 2019 String
uptime_s 703 Int32
make Minka String
model F1001 String
branding_profile MINKA_F1001 String
bondid null
upgrade_http True Boolean
api 2 Int32
_ 94814eda String
extra null
*** Token ***
“…” “…” String
*** Device Info: Dyno XL (1) ***
1 HSPI_AKBond.DeviceBondDevice+BondDeviceInfo
ID 1 String
name Garden Side Fan String
type CF String
location Great Room String
template null
actions
TurnOn, TurnOff, TogglePower, SetSpeed, IncreaseSpeed, DecreaseSpeed, TurnLightOn, TurnLightOff, ToggleLight,
SetBrightness, IncreaseBrightness, DecreaseBrightness, CycleBrightness, SetTimer, BreezeOn, BreezeOff, SetBreeze,
SetDirection, ToggleDirection,
List`1
_ 06b59e9b String
commands null

  • 1.BondDeviceInfo.state HSPI_AKBond.DeviceBondDevice+_State
    _ 0d23128c String

1.BondDeviceInfo.properties HSPI_AKBond.DeviceBondDevice+_Properties
_ 7061dadd String
*** Device Properties: Dyno XL (1) ***
1 Dictionary2[String,Object] (Lenght 5) max_speed 6 Int64 breeze_max_speed 6 Int64 breeze_min_speed 1 Int64 breeze_period 30 Int64 _ 7061dadd String *** Device State: Dyno XL (1) *** 1 Dictionary2[String,Object] (Lenght 9)
power 0 Int64
speed 1 Int64
light 0 Int64
brightness 1 Int64
brightness_cycle_phase -1 Int64
timer 0 Int64
breeze 0, 50, 50, JsonArray
direction 1 Int64
_ 0d23128c String
*** Device Commands: Dyno XL (1) ***
1.Commands Dictionary`2[String,Object] (Lenght 0)

“KSMW…39” and “KSMW…66” are the Bond IDs, “1” are the individual device IDs.

Currently all Smart-by-Bond products (like your Dyno XLs) expose only one device, and it always has an ID of “1”. The reason: soon enough, there will be Smart-by-Bond products that expose multiple devices “1”, “2”, “3” & “4”. And this makes the Smart-by-Bond API and the Bond Bridge API one and the same.

I can’t tell by that log what the problem is, you’re better off asking @alexbk66.

I’m pretty sure he is using the device ID only. That is what he uses in the Bond Bridge devices. And the device ID is all I see for ID in the device list he displays. I think he needs to combine the Bridge ID with the Device ID to get a truely unique ID. It works OK to just use the device ID for a single bridge, but I’m guessing the device ID is always 1 for a Smart by Bond bridge

Ah, yes, there’s the problem. Device IDs are unique on a per-Bond basis, but not globally. Bond ID + Device ID should be used as the fully-qualified device ID when working with multiple Bonds.

For Bond Bridge devices created in the V2 platform, the ID is a randomly generated 32-bit number (displayed in hex). There’s a negligible chance of collision even if you don’t use the Bond ID + Device ID approach.

However, in the V1 platform, all resources were assigned sequential IDs. These IDs migrate over to V2, and it’s much more likely for these devices to have conflicts. I’ve seen this once in the Homebridge integration (the issue: Ids are duplicated across bonds · Issue #52 · aarons22/homebridge-bond · GitHub). This is not exactly the issue affecting you, but it is in the end the same thing.

That’s right.

2 Likes

Just to reiterate @jacob’s point, KSMWDCE75139.1 or ZZBL72842.aabc02d7 would be universally unique device identifiers. The device id 1 or aabc02d7 is only unique within a Bond unit.

1 Like

One things to note. I removed the second Smart by Bond fan using the Bond App until Alex can fix the AK Bond plugin so I could continue testing without the AK Bond plugin getting confused.The removal process said it would not unpair any remote, but it appeared to do a factory reset on the fan and I had to repair the remote. Just so you know …

Ah, was the fan on a firmware version before v2.9? We made the change to prevent factory reset from forgetting the paired remote only in v2.9…

Thanks for pointing this out.

So, we should either remove that text promising the remote will not be unpaired, or do a check for firmware version on SBB devices and warn that the remote will need to be repaired if fw < v2.9. @marcio FYI

v2.6.7.5. I’m running the beta Bond App so it is showing me that I can update to v2.10.12 beta. Should I do that or should I uninstall the beta app and reinstall the release app?

Also, what does the CycleBrightness action do? Alex wants to know if I want him to implement that in his plugin.

The beta is fine.

CycleBrightness is used internally. Should probably be hidden on the API. It is the action that corresponds to holding down the light button on the remote for an interval of time. No need to use it in integrations as you can already express increase/decrease/set intents.

The problem is - it reports

image

Ineed to check where the proper ID comes from - I assume mDNS…

PS: Why the post is marked [SOLVED]?

The problem is that this fan is using pretty old firmware, the "bondid" field was added in v2.7.10.

Ok, I added workaround to use mDNS id if bondid is null.

This only breaks one feature of my plugin - adding Bridge manually if mDNS doesn’t work for any reason.

Currently user can add the device manually, set IP address - and the bondid will be received from the bridge.

But hopfully nobody needs this… And hopefully SBB firmware will be fixed to return proper bondid.

Back to the problem. Yeah, I do use the device id (not Bridge ID) as unique identifier for HS devices.

That I will fix.

And there’s no way to upgrade?

Unrelated question - to get authorisation token - users need to disconnect power from fans?

It’s as easy now, not lik just unplug the usb cable :thinking: