A1a template up/down lights

I’m on 2.18.1 and it doesn’t seem right. And my users complain too:

If I control the lights with the Android app they work correctly. When both lights are off on the Android app HS3 shows the “UpLight” to be ON and the “Light” and “DownLight” to be OFF. (Incorrect)

If I turn the “Bottom Light” on on the Android app, HS3 shows the “UpLight” to be off and the “Light” and “DownLight” to be ON. (Correct I guess)

If I turn on both lights with the Anroid app, HS3 shows all three lights to be ON (Correct I guess).

If I have on the “Top Light” on int he Android app, HS3 shows the “Light” and “UpLight” as ON and the “DownLight” as OFF (Again correct I asssume).

If I try to control the lights from HS3, things get weird.

v2.10.16 is a firmware version, not the mobile app version.

Seems like your integration is showing the top light to be on when up_light is 1, rather than checking for both up_light and light to be 1. And similar for down_light.

So you are saying there was a fix between 2.10.15 and 2.10.8? And the users should update their firmware?

Yes, it does just display each state separately. But I’m not sure how to handle your “logic”.

I can change both light and up_light to off when just light goes off. But this will actually break your logic - because user will think that up_light setting is actually off when it’s not.

Take speed fan for example - when the fan is off - the speed doesn’t change to 0, so the user knows - when they switch the fan on - it will go to last speed.

So if you are trying to be consistent here - I don’t mind, but I don’t know how to handle this.

Please help me here.

On bridge devices, we hide speed state when the power is 0 as well. On SBB, we gray it out to make it clear that it’s off.

If this is presented in a way that’s clear, then fine. But

If I control the lights with the Android app they work correctly. When both lights are off on the Android app HS3 shows the “UpLight” to be ON and the “Light” and “DownLight” to be OFF. (Incorrect)

this user is already confused by the presentation of all of light/up_light/down_light at once. The user’s state is (0, 1, 0) (light, u_l, d_l), but the user believes the top light should be on because up_light is 1.

There was no intentional “fix”, but I tested the sequence of commands/actions you posted and it’s all working as intended (correct state transitions + signals) on v2.10.15.

Try upgrading to v2.10.15, see if you can reproduce your issue, and if so, give me some steps to reproduce it myself and we’ll go from there.

How do I upgrade? I asked actually in another thread if there’s a simple command to upgrade to the latest firmware, without specifying the server, port, file name, etc.?

Like Shelly devices just send /ota comand

For now I wouldn’t try to upgrade using the API, I’d use the app. We need to decide how to properly expose what upgrades are available publicly, or just provide a shortcut like you mentioned. Something like /v2/upgrade {"type": "beta"}.

The versions of the apps available in the store upgrade to one version (v2.10.8), the versions available to Beta apps is v2.10.15.


@jacob, @merck I think you should re-consider your idea on this. I can work-around - around-your-work-around in HS integration, but I would like to avoid extra logic on top of your logic.

Consider another scenario, in addition to what I described before:

Top Light Bottom Light ( light up_light down_light )
1 Top Light is ON in the app ON OFF ( 1 1 0 )
2 Turn off Top Light in the app, up_light is still on OFF OFF ( 0 1 0 )
3 Turn on Bottom Light in the app, up_light changes to off OFF ON ( 1 0 1 )

So the up_light becomes off when we switch ON the Bottom Light. Which completely breaks your ‘logic’!

Firstly, do you have a device in front of you with an actual UpDownLight? It can be a bit counterintuitive if you’re just looking at the API. The key thing to keep in mind is, the actual value of the up light circuit will be the logical AND of the light and up_light variables.

What you describe in your table is exactly what the intended behavior is. Step back from the state variables for a minute and consider the user experience: in step 3, the user expressed the intent TurnDownLightOn in the context of both light circuits being off. Clearly they want just the DownLight to turn on.

The reason in step 2 we keep up_light remembered is so that if the user expresses the TurnLightOn intent, we can restore just the UpLight. (Similar time how we remember also the speed or brightness.)

So, to quote our API docs, I think you need to consider the logical AND and you’ll be in good shape:

If both up_light and light are 1, then the up light will be on, and similar for down light.

Note that both up_light and down_light may not be simultaneously zero, so that the device is always ready to respond to a TurnLightOn request.

I guess you may be right… And no, I don’t have the device.

When I downloaded the Beta App it installed v2.10.17, not 2.10.15.

My experience with the A1a template is the API and the Bond App (v2.10.8) work the same way when the “Trust State” is ON. And the only thing that is broken that I found so far is Google Assistant integration and the “StartUpLightDimming” function (both in the API and Bond App). The StartUpLightDimming does dim the up light, but leaves the Bond App and API in a messed up state afterwards (unsynchronized to the physical lights).

In my opinion, the concept of a pseudo “light” device that controls both up and down lights together is flawed from a user perceptive and should not exist. Especial when combined with dimming functionality. It is just too confusing and prone to user error to be useful.

Ok, I implemented this logic in ver, let the users have fun testing.
It’s almost 2:30 AM :sleeping:

1 Like

Good find and thanks for the report! I’ve reproduced this, set up some automated tests in this corner of the API, and patched it up. I’ll get a v2.10.18 out to beta shortly. If you’ve got some time, we’d love some testing feedback on this.


There are integrations which can only support a single light. Think of it as inheritance in object-oriented programming… you can ignore the abstract interface of “Light” if you want to.

But I hear you — we need to make this more clear in our docs to avoid confusion.

There is no 6-Speed fan template with only one light. There is only A3 which enumerates up and down lights. Is there any way in the API that the code can tell that UpLight has be deprecated (deleted) in the Bond App?

@CJMH it’s available now

Tested and A1a works great! Thanks. Is there any possibility of getting a template with a 6-speed fan and only one light out soon? I’m happy to test …

Awesome! Thanks for testing it out.

It’s available in the same firmware, named A3a, but isn’t yet enabled on the database search. I just started the deploy of a version of that service with it enabled, so it should be available in a few minutes. The description will be “6 speeds, 1 light”. This service is in “the cloud”, so no need for any upgrades on your side for this.

EDIT: you should see it now.

1 Like

Tested v2.10.18 and works fine with both the Bond App and the AK Bond Homeseer plugin. I am not sure we are on the same page with regards to the dimmer function. v2.10.18 seems to work much better with the dimming function.

I thought the A1a template was working correctly in v2.10.18, but v2.10.21 seems to have broken it or possibly the fact that my HS plugin is now using push notification has broken it. The issue is that if both lights are ON (and synced with Bond) and the TurnLightOff action is issued to turn off both lights, only one light physically goes off, but the push notification from Bond indicates that Light is OFF which should indicate that both lights are off regardless of the state of UpLight and DownLight. And the light that is left ON is now out of sync with Bond.

I am pretty sure I tested this without push notifications in v2.10.18. If the commands TurnUpLightOff is followed immediately by TurnDownLightOff the TurnDownLightOff gets an error, but the push notification again indicates that the Light is OFF (indicating both lights are OFF) and one of the physical lights is still on. Again, the light that is left ON is out of sync with BOND.

If there is a one second delay between the TurnUpLightOff action and the TurnDownLightOff action, it works correctly.

Here is log (reverse chronological order) from AK Bond the HS integration (plugin) when sending two actions in a row:
Mar-04 12:02:50 PM AK Bond [480]: Execute cmd: /v2/devices/27a50892/actions/TurnUpLightOff/
Mar-04 12:02:50 PM AK Bond [480]: Device: Bond Hub Set to -1000
Mar-04 12:02:50 PM AK Bond ERROR [480]: [Bond Bridge] ZZCC69147 ( Execute ‘/v2/devices/27a50892/actions/TurnDownLightOff/’: Status: ‘Error’ (ReceiveFailure). Error: ‘Error getting response stream (ReadDoneAsync2): ReceiveFailure’.
Mar-04 12:02:50 PM AK Bond [480]: Execute cmd: /v2/devices/27a50892/actions/TurnDownLightOff/
Mar-04 12:02:50 PM AK Bond [480]: BPUP status update: {“B”:“ZZCC69147”,“t”:“devices/27a50892/state”,“i”:“050000f6747c5e94”,“f”:100,“s”:200,“m”:0,“b”:{“po wer”:0,“speed”:1,“light”:0,“up_light”:0,“down_light”:1,"_": " f1a45ddf"}}
Mar-04 12:02:50 PM Device Control Device: Bond Sue’s Room Sue’s Fan Down Light to Off (-19)
Mar-04 12:02:50 PM Device Control Device: Bond Sue’s Room Sue’s Fan Up Light to Off (-15)
Mar-04 12:02:50 PM Event Event Trigger “Sues Room Events All Lights Off - 1”
Mar-04 12:02:50 PM Z-Wave Device: Upstairs Sue’s Room Sue’s Room Central Scene Set to 2002
If I change the event to wait 1 seconds between sending the turn up light off and turn down light off, it works properly.

FYI Trust state is ON in the Bond APP.