FACER Community

$#DISDAYTIME#=true?100:0$

Hi, and welcome.

You are right. It certainly doesn’t seem to work on subsequent days in the creator or previews. Even the text element showing the state of DISDAYTIME stops changing so it’s not the conditionals.

I’ve run up a quick sample to see if anyone can spot what is wrong:

1 Like

In my experience it does not work in preview mode, but it does work on the watch.
There is a delay though. Mine was usually between 5 and 20 minutes off (in relations to the sunset and sunrise the watch reported).

To be on the safe side, try $#DISDAYTIME#==true?100:0$ (double “=”) and instead of false you can just switch the numbers: $#DISDAYTIME#==true?0:100$

2 Likes

I’d call that a bit of a large bug that it doesn’t even work in creator properly, so to test it works perpetually you have to sync your draft and monotor it on a watch for days before continuing work.

1 Like

I use disdaytime for my lume layers so they only glow after sunset. And as Mattie says those tags only work for the current day in creator but they do work properly on the watch. (That’s one of a number of things that behave differently in creator sand on the watch). I’ve also noticed the delay, but maybe that’s due to the tag needing to pull that data from the weather not the time? So maybe if the weather check interval is every 30minutes it would explain the variable delay. But I’ve learned to have confidence in the tag. So you shouldn’t have to monitor it on your watch for multiple days. If it works correctly in the current day in creator you should be good

2 Likes

@michaelavascarlet197 Welcome . Make sure you use false not FALSE . I never bother . I always use true and just swap the toggle values . As Mattie says == insurance .
This tag will not simulate beyond today .

1 Like

I am going to assume that this is because, to save resources, dusk and dawn times past the current day are not loaded on creator or preview startup. OK, all of them for all of time might be a resource drain but @Facer_Official, 10 days should be enough for testing purposis (not the sea mammals of course). Even 5 would do the trick just to give us confidence in the work we are doing for you.

Raised this as a feature request: Please add sunrise/sunset data for at least 5 days on load. I appreciate any votes that come its way.

1 Like

It’s always LA time as well. 5 days of LA time will just be misleading for the rest of the planet… DISDAYTIME comes from the Weather Station Location. As part of SR SS If it works one day on the Sim it will work on the watches that have a connection to the Open Weather Station that is Logicaly nearest to you.

1 Like

Location should come from your account location setting. In designer and preview.

1 Like

Does our account have a location? The creator always shows LA for me. Which I believe is Facer HQ. …or are you saying it should not that it does?

2 Likes

There is a profile option for location but it is free text so possibly hard to use. It would be very nice if it did, given a match found.

1 Like

@rob.fisk @kvansant. The Apps on my Phone and Tablet show the correct Location and DISDAYTIME simulation.

I’m my testing, it does not work on my watch the day after I made it in creator.

1 Like

I have been using $#DISDAYTIME#==true?100:0$ and $#DISDAYTIME#==false?100:0$ on my personal watch faces that are unpublished and only I wear. I never have problems with it except not changing until the information update in Facer which is usually fairly close. But it keeps on working day after day. The Facer creator only works with it on the current day, and I use 8:00 am & pm to check its function. I would recommend to prevent issues, use the double equal sign (==) and not the single one. Double equal signs are just a good practice to avoid issues in any expression used in Facer.

1 Like

@michaelavascarlet197 Stand by. #DISDAYTIME# does not work on all watches. I think it is Tick Watch that does not like it. When I get on my Laptop I will post here a Grunt Formula that is actually more robust but a bit longer. :joy:. Sorry I might Forget. I have that problem these days. You could offer a cautious reminder if I have not got back in a couple of hours. :+1::wink:

Please try this for Opacity . 100% during Day Light

$(((#DH#)*60)+#Dm#)<(((#WSH#)*60)+#WSm#)&&(((#DH#)*60)+#Dm#)>(((#WRH#)*60)+#WRm#)?100:0$

Have Fun . :sun_with_face: :waning_crescent_moon: :+1:

Be careful with that one, those short sunrise/sunset tags do not work on all watches either :wink:

1 Like

@ThaMattie @kvansant . I have played a lot with SR SS DISDAYTIME and the Formula Above . One of or problems is there are a few Sun Rise and Sun Sets Civil , Aeronautical and the Like . The times reported by Open Weather are within 1 or 2 minutes of other data I can pull from the Net . It is the classic where the Sun is Half clipped by the Horizon . I live very near the sea so see these things well in the Spring and Autumn being in the UK . I think one of the problems is Open Weather Data updating to the Watch . There is nothing any of us can do about that . I find that if I am not continually syncing other stuff and just Leave MY Day Watch running on its own for a few Hours everything is updated as well as I would expect . Weather , LAT LNG , DNOW , Time Zone (AOD only ) ,
I personally feel if this one can be kept On Topic it will be very useful . The Author Has given it a Good Title . Got My Attention .

2 Likes

@ThaMattie . That formula if that is what you mean is a long one for me . Is there something more robust then that will work across all watches ?

Having had two (cheap) TicWatches that I used for testing. (One was a TicWatch E first gen and the other was a TicWatch S2, both of them dropped dead before being 6 months old) I discovered they work fine with #DISDAYTIME# but only if you use true/false. If you use 0/1 only Samsung Tizen will display it correctly. My question is, where would you use #DISDAYTIME# other than the day or night filter?

2 Likes

@russellcresser I’m taking about the tags. Looking at Facer documentations, these are what I refer to as the “short” tags for sunrise/set:

TAG DEFINITION SAMPLE OUTPUT PLATFORMS
#WRh# Sunrise hour (1-12) 5 All
#WRhZ# Sunrise hour (leading zero) (01-12) 5 All
#WRH# Sunrise hour (0-23) 5 All
#WRHZ# Sunrise hour (leading zero) (00-23) 5 All
#WRm# Sunrise minute (0-59) 50 All
#WRmZ# Sunrise minute (leading zero) (00-59) 6 All
#WSh# Sunset hour (1-12) 8 All
#WShZ# Sunset hour (leading zero) (01-12) 8 All
#WSH# Sunset hour (0-23) 20 All
#WSHZ# Sunset hour (leading zero) (00-23) 1 All
#WSm# Sunset minute (0-59) 6 All
#WSmZ# Sunset minute (leading zero) (00-59) 6 All

End deze would be the “long” ones:

TAG DEFINITION SAMPLE OUTPUT PLATFORMS
#WSUNRISE# Time of sunrise 5:50 AM All
#WSUNSET# Time of sunset 8:06 PM All
#WSUNRISE24# Time of sunrise (24) 5:50 All
#WSUNSET24# Time of sunset (24) 20:06 All
#WSUNRISEH# Hour of sunrise 5 All
#WSUNRISEM# Minute of sunrise 50 All
#WSUNSETH# Hour of sunset 8 All
#WSUNSETM# Minute of sunset 6 All
#WSUNRISEH24# Hour of sunrise (24) 5 All
#WSUNSETH24# Hour of sunset (24) 20 All

On my watch the “short” ones are blank, but the long ones work.
They have similar information, and you can achieve the same you are doing with the long tags too.

4 Likes

@ThaMattie . Now I remember seeing your work on this . So use the long Tags yeah .Cool . So much to Learn . Thanks for the heads up . I will make a Test .

2 Likes