A1a template up/down lights

Integrations
1

Customer reported (and I confirmed) an issue with A1a up/down lights status reporting - ‘up_light’ and ‘down_light’ don’t reflect the light states correctly.

[EDIT] And should it have ‘light’? I don’t think so.

2

Yes, it’s mentioned in passing here.

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

I’ll expand and clarify in the docs, but here’s a rundown:

light is whether the Bond believes either light to be on. If light is 0, neither light is believed to be on, and in this state, if up or down_light is 1, this means that this light is remembered as the last activated light (or lights, if both are 1). This is similar to the Power/Speed feature interaction, where a power of 0 with speed 3 means that the fan was last on speed 3.

“TurnOffLight” turns off only the light that is currently on. “TurnOnLight” turns on only the light(s) that have 1 as their state value, i.e. the last-on light(s).

To match our app’s state highlighting, light && up_light gives you “is the top light on?” and similar for down_light.

If the above does not solve your problem, find out if this user sees the proper state in the Bond app. If not, then we’re facing a different problem, my recommended solution is:

  1. Use the remote to make the Bond’s “believed” state match the actual state
  2. Enable trust_state in the device settings
  3. If at all possible, avoid using the physical remote, as this could cause the states to get out of sync (we are working on listening for the remote’s signals, but that’s at least months out)
3

Crap, this breaks my brilliant idea of using a map to configure devices to avoid complex code, i.e. for UpLight control that much code is required:

StateMap["TurnUpLightOn"] = new StateMapItem("up_light", 1, "on.gif", "On", ePairControlUse._On);
StateMap["TurnUpLightOff"] = new StateMapItem("up_light", 0, "dim-00.gif", "Off", ePairControlUse._Off);
StateMap["ToggleUpLight"] = new StateMapItem(ePairControlUse._On_Alternate);
StateMap["StartUpLightDimmer"] = new StateMapItem(ePairControlUse._Dim);
4

I can see what you are trying to do here, but I’m afraid the logic is a bit twisted. Consider the following sequence of button press in HomeSeer:

Button State ‘light’ State ‘up_light’ State ‘down_light’ Comment
TurnUpLightOn on on off
TurnDownLightOn on on on All lights on
TurnUpLightOff on off on
TurnDownLightOff off off on All lights off
TurnUpLightOff (again) on off on DownLigh on

So the problem - after clicking UpLight OFF when it’s already OFF - actually turns DownLight ON. Because its status stayed “ON” when both lights were OFF.

5

Actually, it’s same problem in the Bond app logic - in the sequence table above just replace action commands with the app buttons, i.e. the following sequence in the app:

“Top Light” (on) -> “Bottom Light” (on) -> “Top Light” (off) -> “Bottom Light” (off)

Now both lights are off. Now send “TurnDownLightOff” - result: “Top Light” becomes ON.

6

The last action in this table is where the state transition isn’t correct.

When (light, up_light, down_light) is (0, 0, 1), TurnDownLightOff should not change the state. If the state is untrusted and we only have a toggle (as is the case with A1a), we send a toggle signal. If we have on/off signals or the state is trusted, no signal is sent at all.

Setting up my double-light kit, looking in to it.

7

How is it going @jacob?

8

Commands: “Top Light”, “Bottom Light”, “Top Light”, “Bottom Light”. State is now (0, 0, 1) (light, top_light, down_light, respectively). This state represents “the lights are off, and the bottom light was the last light on”.

Two scenarios:

  1. The Bridge trusts this device’s state (“Trust tracked state” flipped “on” in the device settings). “TurnDownLightOff” action -> No signal, no state change.

  2. The Bridge doesn’t trust this device’s state. “TurnDownLightOff” action -> Down Light toggle signal, but no state change. Basically we assume that the “real” state was (1, 0, 1), so we send the toggle and reach the initial state (0, 0, 1).

Both scenarios are working as expected in v2.10.15. I don’t have time to test them on v2.10.8.

9

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.

10

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.

11

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.

12

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.

13

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

14

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.

2 Likes
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’!

16

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.

17

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

18

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

19

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.

20

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

1 Like