I just bought and installed a Minka-aire 6-speed fan. It is has only one down light, but when I pair it with Bond it had both a up and down light.
Customer reported a valid point: if they delete a “command” - is it possible to find via API that the device was deleted? Because in my integration I still get a full list of actions - so still I create unnecessary devices.
I’m the customer that is working with alexbk66 on the Homeseer integration.
I want to first say that I appreciate Olibra for making this Bond device and Alex for developing a Homeseer plugin for it. At this point the Homeseer beta plugin (AK Bond) is working reliably on my Homeseer Zee S2 Raspberry Pi based platform and needs a few minor changes before it is released. However, the Android Bond App and Bond API have some issues that need addressing.
I am currently running Bond firmware 2.10.8, but I have also tried the beta 2.10.17.
First, I want to discuss the “Trust State” option in the Bond. I understand the issues with controlling devices that only have a toggle command. However, the option of turning off the “Trust State” only leads to the physical device getting out of sync with the Bond state. So, at the very least, “Trust State” ON should be the default. Harmony has the same issue with controlling entertainment equipment that only has a toggle command for power. However, they don’t have any option to NOT trust their own state. They do, like Bond, have an option to correct the state if it is out of sync. From my experience, having the “Trust State” OFF by default on Bond was confusing and made me think that the Bond did not work right and was not ready for prime time. For instance, with the “Trust State” OFF, if I told Google Assistant to turn of a fan light OFF that was already OFF, Bond would turn it ON and as I remember the Bond state was then out of sync with the physical light. This is very confusing. With “Trust State” ON, Google Assistant worked correctly. Since you have a way in the Bond app to correct the state, it seems having this “Trust State” option is not needed or at least the “Trust State” should be defaulted ON.
API issue with devices that have an up & down light (Template A1a). The up and down light work correctly in the Bond App with the “Trust State” ON, but even with “Trust State” ON they get out of sync with API commands. I eventually gave up and deleted the up light in the Bond App and restarted the AK Bond plugin on Homeseer and then there was only one light enumerated and it worked correctly if the “Trust State” was ON.
If I remember correctly, the issue had to do with having both lights on and then turning one of the lights (Up.Light or Down.Light) off. If I used the “Light” control to control both lights that worked correctly as I remember but I may not remember exactly what did not work correctly. It is also confusing to turn the “Light” off and still see the “Up.Light” and/or “Down.Light” show that it is ON. I assume these indicators are showing the last state of those lights, but until you understand that it is very confusing. It would be much better if there were just two devices (Up.Light and Down.light). This would be consistent with the way the Bond App works and how the remote works.
API issue with the A3 template. I just installed a Minka-aire 6-speed fan with a down light. When pairing it with the Bond App the only template I could use was the A3 template that has both an up light and down light. I deleted the up light in the Bond App, but, unlike with the A1a template, the API still enumerates the “uplight” and the “light” devices. This is confusing to say the least. However, if I use only the “light” or “down light” device through the API (AK Bond) things seem to work correctly if the “Trust State” is ON.
I tried the beta 2.10.17 firmware which did not help the enumeration of deleted devices issue, but did break the dimming function in both the Bond App and API. If start the dimming process (in 2.10.17) and then stop it, the physical light and the Bond state where usually out of sync. To make matters worse, if I tried to fix the state in the Bond App settings menu, the fix state showed the device in sync, so it could not be used to correct the state. I reverted back to 2.10.8, but had to clear the Bond App data and cache before the dimmer function would work correctly again.
In my opinion the concept of creating three devices (up light, down light, and light) for two physical devices is confusing at best and trying to keep track of the state of the three devices with the complication of the trust state option is very complicated and is probably the reason the logic in the firmware does not work correctly.
I am a big believer in the KISS principle. Making things more complicated without bringing some significant improvement to the user experience is a bad idea. In this case, the remote has an up light button and a down light button. This is mirrored in the Bond App with the same idea. There aren’t three light devices in the Bond App for fans with an up light and down light. I suppose your position could be that it is up to the integration developer to make their app more consistent with the way the remote and Bond App work by inserting a bunch of logic to translate the three devices back down to two devices, but why add all that complexity to something that should be very simple? There are only two physical devices (up and down lights). Neither the remote or the Bond App have three devices. Just enumerate and keep track of those two devices in the firmware and everyone’s logic would be very simple.
In the case of the AK Bond devices in Homeseer, the AK Bond plugin creates a icon (device) for every device (and action on that device) as enumerated by the API. This results in a huge mess of devices and action icons that clutter the screen and make the user go searching for the action icon they want to click. This is exactly the opposite of the KISS principle. A typical user simply wants to turn the up/down light off or on and set the fan speed to off or to whatever speeds the fan supports. There is no need for a toggle actions (icons) in the API. I know this could be taken care of by Alex’s Homeseer plugin, but I don’t think these extra actions and especially the third pseudo light device brings anything to the table except user confusion.
We made this setting off by default for a certain class of users. Here’s their story:
Here’s the branch in behavior:
With trust on: The light does nothing! I ask again, still nothing. I don’t realize (because it’s not intuitive) that if I say “Alexa, turn off my light” that it’ll turn on. I contact customer support or just return the Bridge immediately.
With trust off: The Bridge assumes its state belief is wrong and it invalidates it, and performs my desired action.
This sort of user (one who uses both the physical remote and voice control frequently) makes up a big portion (majority?) of our user base. We may be wrong, but we think this’d cause more frustration for more people than the alternative. We know we need to do better and lead people to this feature and explain it, and we’ll probably add it to the device setup flow soon.
Our API exposes one device with two lights (and a fan, etc.). I recommend one of the following two presentation styles:
We use approach 1 in the Bond Home app, and approach 2 in our voice assistant and SmartThings integrations (we’ll likely be moving to approach 1 in those as well sometime).
I don’t recommend combining the two approaches. This is the cause of the 3-device situation you’re seeing.
There is no perfect solution to this. Using the remote and the Bond bridge at the same time can only lead to confusion no matter what mode it is in. This is especially true when using it with an home automation system like Homeseer or SmartThings.
One of the biggest advantages of home automation systems is that they can be set up to automatically turn things on and off based on some trigger (time, door opening, motion sensor detecting motion, etc.). Using the remote in any of those scenarios breaks that functionality no matter what “Trust Mode” one sets.
I would ask if you are going to use Google Home or Alexa to control the fan, why confuse the matter by using the remote as well. Just use the Bond App on any phone or tablet and Google Home or Alexa. Perhaps better documentation/warning about using the remote would help. I know if I tried to get my wife to use both the remote and the Bond App/Google Home, she would unplug the Bond device and toss it in the trash out of frustration.
My plan is to hide the fan remotes in a drawer (like I did with the entertainment remotes) and use a scene control wall switch (ZEN 30) connected to Homeseer to control the fan through Homeseer / Bond. Or just use Google Home assistant. You don’t have to be near a remote or a scene control switch for that. That is the beauty of Google Home and Alexa.
The advantage of the Harmony Bridge is that it has its own remote. You deep six all your other remotes and all is well. Even my wife can use the Harmony remote, but I do have to tell her not to touch any buttons on the actual entertainment equipment or all hell breaks loose.
I guess the bottom line is the Bond Bridge confused a guy that has an MSEE degree and has developed products for 40 years. So my first though was that the Bond Bridge was a piece of junk didn’t work right with Google Home and was just unreliable. Once I found the “Trust State” switch and turned it on everything got much better and understandable.
Ok, but there are still problems.
No matter what “Trust State” the A1a device is in, API calls can do unexpected things and get the Bond state out of sync with the actual device (light). To fix this I thought I deleted the uplight with the Bond App, but what I actually did was delete the A1a device from the Bond Bridge and re-paired it as an A1 fan which has no uplight. The A1 device works correctly through the API when in the “Trusted” state, so I am happy with that.
The Minka-aire speed fan I have has only a down light, but instead of having two templates (A3 and A3a) there is only one template (A3) for three lights (uplight, downlight, and light device). I can delete the up light from the Bond App, but this does not delete it from being enumerated in the API. I guess what you are saying is that Alex should take care of this in his integration implementation.
Besides this confusion there is a problem with dimming in the A3 fan. The Bond App seems to work correctly, but the API is very unreliable. I have not checked with Alex, but I assume that when I get AK Bond to send the “Strat Diming Downlight” command it only sends it once. Sometimes this works correctly, but sometimes the light will start dimming then flash on and off, then stay on or just go off or sometimes it will start dimming again and then flash on and off. Often when I “stop” dimming the light will be in the OFF state while the Bond App thinks it in the ON state. Try to fix the state in the fix state menu does not fix the state. I have to use the remote to toggle the state to get things back and working. I am using the “trust state” mode. I have not tried that mode OFF as it is useless in the Homeseer home automation environment.
I had not noticed this odd behavior until I upgraded to the beta 2.10.17. Then I reverted back to 2.10.8, but it did the same thing. So I deleted Bond App data and cache on my phone and then it seemed to work correctly, but now it is back to being weird again. However, the Bond App seems to do the dimming correctly so it is not entirely busted. In both cases (Bond App and API) I see the Bond Bridge blinking its light repeatedly while trying to dim. I assume this is an issue with the Bond firmware and not AK Bond (Homeseer integration) since dimming the A1 fan light works fine with AK Bond (API).
Did I totally mess my Bond Bridge up by upgrading 2.10.17 and then downgrading to 2.10.8?
Yes, that’s correct. It sends “Strat Diming” command. Then when you press “Stop” - it sends the Stop command and dimming should stop.
Can you actually select the template manuall when you add a device? Or Bond App selects the template based on your remote button press?
So you mean I should add some logic in HS integration to work around your logic? And show that downlight state is “Off” when API reports “On” and “Light” state is Off?
Question from alexbk66: Can you actually select the template manuall when you add a device? Or Bond App selects the template based on your remote button press?
Once you start the pairing by pressing one of the buttons in the Bond App activating that button onthe remote you can select a number of different templates inthe Bond App which may or may not work for your fan and you can then select another template or you can individually program the buttons. There are two problems with individually programming the buttons. First, there is no “StartDimming” button, so you lose that functionality. Second, I tried this programming “Speed 1”, “Speed 2”, “Speed 3”, “Reverse” and “Toggle Light”. The I restarted AK Bond and a Test.Fan device showed up in the HS web interface but it has no actions associated with it. The config page shows no actions as well.
However, the HS Mobile and HS Touch apps show all the actions buttons I recorded while paring in the Bond App. Not sure why that is. I will send the config page for the test fan I created by individually program remote buttons on the Homeseer website.
Yeah, the Bond API returns empty actions list for this device.
The problem was that I did not program the fan off button so that probably got the Bond firmware confused as to how to handle a fan that only had speeds 1, 2, and 3 with no OFF so it enumerated two devices in the API.
We need to offer you a single-light version of this template. I’ll get that available ASAP.
The other issue with this A3 template light is with dimming. If I use the physical remote the dimming function works smoothly. If I use the Bond App or the API to start the dimming things are not so smooth. It seems the API is worse, but both cause problems. The problem is that the dimming may start, but then the light can go off, or it can flash on and off. I assume this because (and this just an assumption) the way dimming works is the RF TOGGLE command is sent over and over and after a specified time the light device starts dimming until the TOGGLE command is no longer repeatedly sent. And the issue is that something in the Bond Bridge causes the stream of TOGGLE commands to get interrupted long enough that the light device thinks dimming has stopped. Then the next TOGGLE command in what was supposed to be a continuous stream causes the light to go off. And this is what gets the things messed up.
For some reason this never happens with the A1a template in either API start dimming command or the Bond App. Perhaps the A1a is more forgiving of a short interruption in the stream.
BTW the A3 fan is in the same room as the Bond Bridge and the A1a fan (the one that always works smoothly) is on a different floor and much further away, so it can’t be that the A3 light device is having trouble “hearing” the Bond Bridge.
This is spot on. Some versions of this same remote use the ToggleLight signal repeated continuously. Some use a distinct signal. A1 (and by extension, A1a) has this issue as well, you may have noticed there are two dimmer buttons per light on your A1a. Depending on your receiver, one of the dimmers won’t do anything, or one of the dimmers will toggle your light over and over (! < this is very odd and as far as I can tell is the rarer version). So it seems you’re experiencing the second behavior.
We figured this temporary user inconvenience of manually deleting one button is not as bad as the inconvenience of selecting a remote that’s right except for a button and not understanding why. We eventually want to guide users to test out both dimmers and delete the one that doesn’t actually dim.
We just need to follow through with this double-dimmer logic with A3a. It’s a quick change and we’ll get it in this afternoon. You’ll need to upgrade your firmware (it’ll be v2.10.19) and then either 1) re-record your remote’s signal or 2) go to “edit commands” for the device then tap “reload” at the very bottom. This’ll rebuild the command table with the added dimmer.
EDIT: It’s available now.
I don’t think we are on the same page on the dimming here. I am now using template A3a with a Minka-aire Dyno-XL with the Bond v2.10.18 firmware. I am NOT currently using the bond chip in the Dyno-XL. I am using the Bond Bridge to control the Dyno-XL.
Before v2.10.18, the light would start dimming and then after a few seconds it might go off then come back on and start dimming again or it might go off and on a couple of times, then start dimming again. It was very sporadic. With the v2.10.18 firmware, the dimming function seems much smoother. I have had it only glitch off once so far in my testing and that was when I hit “STOP”. So this seems more like a timing issue with sending the toggle command than with the wrong process (codes) being used. But I really am only guessing as to how it all works. It is just the only thing that makes sense to me is the light is very sensitive to any interruption in the stream of toggle commands being sent. and drops out of dimming mode if it sees the slightest delay in sending a toggle code. Does this make sense or am I barking up the wrong tree?
Would using the bond chip in the Dyno-XL instead of the Bond Bridge help here?
Oh, yeah, definitely set that up directly. You’ll have a much better experience, since there is two-way communication between the receiver and the app.
Yeah, sounds like the receiver is missing a couple packets and interpreting that as multiple taps of the power toggle button.
Except the remote works perfectly with no hiccups. My guess is that the Bond has some variability in its repetition of the RF signal that the remote does not and the Dyno is sensitive to that.
Anyway, the Smart by Bond is much nicer and cleaner as I can use the remote and the Bond App together without the Bond app getting out of sync. Very well done! Definitely the way to go.
However, I am having trouble with the AK Bond integration. The Dyno device came up under the AK Bond plugin at first, but then I restarted the AK Bond plugin and it is no longer communicating with Smart by Bond chip. The plugin is getting the following error. I will discuss this with Alex, but if you have any ideas I would appreciate it.
AK Bond ERROR [622]: ValueChanged(28): System.Collections.Generic.KeyNotFoundException: The given key ‘622’ was not present in the dictionary. at System.Collections.Generic.Dictionary2[TKey,TValue].get_Item (TKey key) [0x0001e] in :0 at HSPI_AKTemplate.ControllerBase.ValueChanged (System.Int32 devID, System.Double value, System.Nullable1[T] oldval, System.String cause, System.String ControlString) [0x00006] in <0b145625452248d283351ee6f6e96e6b>:0
Feb-11 8:49:32 PM AK Bond ERROR [620]: ValueChanged(1): System.Collections.Generic.KeyNotFoundException: The given key ‘620’ was not present in the dictionary. at System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey
That’s a plugin problem, not Bond. The device with ref 622 disappeared. But usually it only happens when you manually delete a HS device.
[EDIT] Interesing, it looks like the dissapeared device ref is 620, not 622. Any clue what happened?