[BUG] #BS# Conditional Not Working post-Facer 3.0

Hi:

I have a an old watch face that I created before Facer went to a web interface. It has been working fine until the last update. Now, Transparency conditionals using $BS$ do not seem to be working. In particular,

   $#BS# == "Charging"? 100 : 0 $

always has a value of 100. Like I said, this has always worked before. I have tried various versions using ‘=’ alone or adding (). None have worked.

1 Like

According to documentation, #BS# should generate 1 or 0. However on watch it displays “Charging” and “Not Charging”. I think the space in “Not Charging” breaks the condition logic and cannot be used there. I did not find any workaround myself unfortunately.
I believe the expression model in Facer needs some serious update, to be able to treat “string expressions”, and also some fixes in documentation and/or tag translation has to be done. So far it is quite inconsistent.

1 Like

@lubomir.moric is right, in more ways than one.

Going off documentation at
http://docs.facer.io/c-advanced/tags/ and
http://docs.facer.io/c-advanced/conditionals/, I tried these:
$ #BS# == 1 ? 1 : 0 $
$ #BS# == 0 ? 0 : 1 $

Failing that, I tried these:
$ #BS# == 1 ? 100 : 0 $
$ #BS# == 0 ? 0 : 100 $

So I stuck #BS# into a text box and observed the following:

  • On the simulator, the value returned was 1.
  • On the watch, the values returned were Charging and Not Charging.
  • The value seemed not to update unless the entire watch face was reloaded.

Next I tried these:
$ #BS# == "Charging" ? 100 : 0 $
$ #BS# == "Not Charging" ? 0 : 100 $

For good measure, I also tried these:
$ #BS# == "Charging" ? 1 : 0 $
$ #BS# == "Not Charging" ? 0 : 1 $

No love! Can someone tell me what’s really going on here? :thinking:

(The Moon Phase watch face that came with my Huawei has a working charge indicator, so I know it’s not a hardware issue.)

Thanks in advance.

@Facer_Official, are #BS# conditionals going to work anytime soon?

Did you try it with only one “=”? Sometimes that condition only works with a single equal sign.

Thanks @eradicator09, I did. @tyhm’s post tipped me off that some folks have tried using single = in their conditionals and found success.

But if I understand @lubomir.moric’s post correctly, #BS# conditionals won’t work properly until Facer can handle "string expressions". The documentation implies that it can, and it’s surprising that it doesn’t.

Hoping it’s a bug that will be patched soon…

Try $#BS#=Charging?100:0$
It won’t work in the editor; it will work in the preview and on your watch.

Thanks for the suggestion, @tyhm!

Sadly, when I sync either $#BS#=Charging?100:0$ or $#BS#=1?100:0$, what I see transparency at 100, regardless of charging status.

I have a Huawei Watch 2176. What are you testing on?

The condition got broken with a space in “Not charging”. So if you e.g. try to put it into a text field, in your watch you will see something like $Not Charging=Charging?100:0$ <- exactly as you see it here.
Conditionals are not well managed by Facer, if you are a programmer, you need to cry from this. It is really lousy coded.

1 Like

Huh. Yeah, I guess it doesn’t work after all - I had it outputting as text. It lights up with Charging and Not Charging, probably as @lubomir.moric said…
I look forward to the Facer gods fixing this…

It seems like working #BS# conditionals are now a moot point.

Since the 4.0 Update, I can see a white charging icon on both Active and Dim sides of all watch faces whenever my Huawei is on its charging puck.

It shows up right on top of the weather icon on my 1200 :heart: bpm watch face:

I’m curious if this is a Android Wear 2 thing. My charge indicator come on at the top of my Huawei watch regardless of the design. Most times the charging screen will replace my Facer face while charging completely. So either this is watch or Android wear driven.

As far as the #BS# condition goes, IDK? Never really used it in a design because of the aforementioned watch defaults.

Has this issue not been addressed yet? I can’t find any sign of an official bugtracker or updates.

(Can’t help noticing that the competitor doesn’t handle conditions using {bc} very well either)