Astro:sun:night#start channel UNDEF and others too

Tags: #<Tag:0x00007f386b630218> #<Tag:0x00007f386b630038>

Where do you live? At this time of year here in mid Finland nights are so short the sun won’t go “low enough” for the astro binding. I noticed same behavior few days ago when my rule threw errors.

So there is no astronomical night and that’s what UnDeff means. I suggest to handle those UnDeff values in your rule to skip part of it and set your “TimeOfDay” item to what ever suits best. For example a new state “MidsummeNight” if your night lightning depends on it.

Here’s a link to astro bindings doc mentioning UnDef:

1 Like

In openhab:

2019-05-20 22:57:15.355 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:moon:local
2019-05-20 22:57:15.363 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled Positional job astro:moon:local every 60 seconds
2019-05-20 22:57:15.547 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:local
2019-05-20 22:57:15.568 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled Positional job astro:sun:local every 60 seconds
2019-05-20 22:57:16.022 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key astro:sun:local in ManagedThingProvider, because it does not exists.
2019-05-20 22:57:16.023 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key astro:moon:local in ManagedThingProvider, because it does not exists.
[...]
2019-05-20 23:07:15.374 [DEBUG] [ding.astro.handler.AstroThingHandler] - Publishing planet Moon for thing astro:moon:local
2019-05-20 23:07:15.578 [DEBUG] [ding.astro.handler.AstroThingHandler] - Publishing planet Sun for thing astro:sun:local

The last two are repeating ones per minute.
And at midnight (because then astro is recalculating):

2019-05-21 00:00:30.024 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:moon:local
2019-05-21 00:00:30.032 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:moon:local/rise#event/START in 84029976ms (at 2019-05-21T23:21:00)
2019-05-21 00:00:30.032 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:moon:local/set#event/END in 23429968ms (at 2019-05-21T06:31:00)
2019-05-21 00:00:30.038 [DEBUG] [ding.astro.handler.AstroThingHandler] - Publishing planet Sun for thing astro:sun:local
2019-05-21 00:00:30.040 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:local
2019-05-21 00:00:30.041 [TRACE] [ding.astro.handler.AstroThingHandler] - Tidying up done future java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@514e7c3e
2019-05-21 00:00:30.041 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/rise#event/START in 16409959ms (at 2019-05-21T04:34:00)
2019-05-21 00:00:30.042 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/rise#event/END in 16709958ms (at 2019-05-21T04:39:00)
2019-05-21 00:00:30.042 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/set#event/START in 73769958ms (at 2019-05-21T20:30:00)
2019-05-21 00:00:30.042 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/set#event/END in 74009958ms (at 2019-05-21T20:34:00)
2019-05-21 00:00:30.043 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/noon#event/START in 45209958ms (at 2019-05-21T12:34:00)
2019-05-21 00:00:30.043 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/noon#event/END in 45269957ms (at 2019-05-21T12:35:00)
2019-05-21 00:00:30.043 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/nauticDawn#event/START in 9989957ms (at 2019-05-21T02:47:00)
2019-05-21 00:00:30.043 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/nauticDawn#event/END in 13769957ms (at 2019-05-21T03:50:00)
2019-05-21 00:00:30.044 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/civilDawn#event/START in 13769956ms (at 2019-05-21T03:50:00)
2019-05-21 00:00:30.044 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/civilDawn#event/END in 16409956ms (at 2019-05-21T04:34:00)
2019-05-21 00:00:30.044 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/nauticDusk#event/START in 76649956ms (at 2019-05-21T21:18:00)
2019-05-21 00:00:30.044 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/nauticDusk#event/END in 80489956ms (at 2019-05-21T22:22:00)
2019-05-21 00:00:30.045 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/civilDusk#event/START in 74009955ms (at 2019-05-21T20:34:00)
2019-05-21 00:00:30.045 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/civilDusk#event/END in 76649955ms (at 2019-05-21T21:18:00)
2019-05-21 00:00:30.045 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/daylight#event/START in 16709955ms (at 2019-05-21T04:39:00)
2019-05-21 00:00:30.045 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Event job astro:sun:local/daylight#event/END in 73769955ms (at 2019-05-21T20:30:00)
2019-05-21 00:00:30.046 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/SUN_RISE in 16409954ms (at 2019-05-21T04:34:00)
2019-05-21 00:00:30.046 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/SUN_SET in 73769954ms (at 2019-05-21T20:30:00)
2019-05-21 00:00:30.046 [TRACE] [thome.binding.astro.internal.job.Job] - Scheduled Instant is null
2019-05-21 00:00:30.046 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/DAYLIGHT in 16709954ms (at 2019-05-21T04:39:00)
2019-05-21 00:00:30.047 [TRACE] [thome.binding.astro.internal.job.Job] - Scheduled Instant is null
2019-05-21 00:00:30.047 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/NAUTIC_DAWN in 9989953ms (at 2019-05-21T02:47:00)
2019-05-21 00:00:30.047 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/CIVIL_DAWN in 13769953ms (at 2019-05-21T03:50:00)
2019-05-21 00:00:30.047 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/ASTRO_DUSK in 80489953ms (at 2019-05-21T22:22:00)
2019-05-21 00:00:30.047 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/NAUTIC_DUSK in 76649953ms (at 2019-05-21T21:18:00)
2019-05-21 00:00:30.047 [DEBUG] [ding.astro.handler.AstroThingHandler] - Scheduled Sun phase job astro:sun:local/CIVIL_DUSK in 74009953ms (at 2019-05-21T20:34:00)

And there is no astro:sun:local:night.

I live in Poland, so I don’t think it is the problem.

1 Like

Calculate sunrise at 0430 and sunset at 2030 does not suggest problems with high latitude.

Do you have any offset or earliest/latest options in your Thing configuration?

Things:

Thing astro:sun:local "Astro sun data" @ "Astro"  [ geolocation="52.33032,20.90932", interval=60 ]
Thing astro:moon:local "Astro moon data" @ "Astro" [ geolocation="52.33032,20.90932", interval=60 ]

Items:

Group gAstro <sun_clouds>

// Times of Day
String TimePeriodOfDay              "Okres dnia [MAP(astro.map):%s]" <sunmoon> (gAstro)

DateTime MorningNightStart_Time     "Początek porannej części nocy [%1$tH:%1$tM]"  <moon>     (gAstro) { channel="astro:sun:local:morningNight#start" }
DateTime MorningNightStop_Time      "Koniec porannej części nocy [%1$tH:%1$tM]"   <moon>     (gAstro) { channel="astro:sun:local:morningNight#end" }
DateTime NightStop_Time             "Koniec nocy [%1$tH:%1$tM]"        <moon>       (gAstro) { channel="astro:sun:local:night#end" }
DateTime AstroDawnStart_Time        "Początek świtu astronomicznego [%1$tH:%1$tM]"   <sunrise>           (gAstro) { channel="astro:sun:local:astroDawn#start" }
DateTime AstroDawnStop_Time         "Koniec świtu astronomicznego [%1$tH:%1$tM]"   <sunrise>           (gAstro) { channel="astro:sun:local:astroDawn#end" }
DateTime NauticDawnStart_Time       "Początek świtu morskiego [%1$tH:%1$tM]"   <sunrise>           (gAstro) { channel="astro:sun:local:nauticDawn#start" }
DateTime NauticDawnStop_Time        "Koniec świtu morskiego [%1$tH:%1$tM]"   <sunrise>           (gAstro) { channel="astro:sun:local:nauticDawn#end" }
DateTime CivilDawnStart_Time        "Początek świtu cywilnego [%1$tH:%1$tM]"   <sunrise>           (gAstro) { channel="astro:sun:local:civilDawn#start" }
DateTime CivilDawnStop_Time         "Koniec świtu cywilnego [%1$tH:%1$tM]"     <sunrise>          (gAstro) { channel="astro:sun:local:civilDawn#end" }
DateTime SunriseStart_Time          "Początek wschodu słońca [%1$tH:%1$tM]"   <sunrise>    (gAstro) { channel="astro:sun:local:rise#start" }
DateTime SunriseStop_Time           "Koniec wschodu słońca [%1$tH:%1$tM]"   <sunrise>    (gAstro) { channel="astro:sun:local:rise#end" }
DateTime DayStart_Time              "Początek dnia [%1$tH:%1$tM]"    <sun>           (gAstro) { channel="astro:sun:local:daylight#start" }

DateTime DayStop_Time               "Koniec dnia [%1$tH:%1$tM]"        <sun>             (gAstro) { channel="astro:sun:local:daylight#end" }
DateTime SunsetStart_Time           "Początek zachodu słońca [%1$tH:%1$tM]"   <sunset>     (gAstro) { channel="astro:sun:local:set#start" }
DateTime SunsetStop_Time            "Koniec zachodu słońca [%1$tH:%1$tM]"   <sunset>     (gAstro) { channel="astro:sun:local:set#end" }
DateTime CivilDuskStart_Time        "Początek zmierzchu cywilnego [%1$tH:%1$tM]" <sunset>             (gAstro) { channel="astro:sun:local:civilDusk#start" }
DateTime CivilDuskStop_Time         "Koniec zmierzchu cywilnego [%1$tH:%1$tM]"   <sunset>            (gAstro) { channel="astro:sun:local:civilDusk#end" }
DateTime NauticDuskStart_Time       "Początek zmierzchu morskiego [%1$tH:%1$tM]" <sunset>             (gAstro) { channel="astro:sun:local:nauticDusk#start" }
DateTime NauticDuskStop_Time        "Koniec zmierzchu morskiego [%1$tH:%1$tM]"   <sunset>            (gAstro) { channel="astro:sun:local:nauticDusk#end" }
DateTime AstroDuskStart_Time        "Początek zmierzchu astronomicznego [%1$tH:%1$tM]" <sunset>             (gAstro) { channel="astro:sun:local:astroDusk#start" }
DateTime AstroDuskStop_Time         "Koniec zmierzchu astronomicznego [%1$tH:%1$tM]"   <sunset>            (gAstro) { channel="astro:sun:local:astroDusk#end" }
DateTime NightStart_Time            "Początek nocy [%1$tH:%1$tM]"      <moon>       (gAstro) { channel="astro:sun:local:night#start" }
DateTime EveningNightStart_Time     "Początek wieczornej części nocy [%1$tH:%1$tM]"  <moon>     (gAstro) { channel="astro:sun:local:eveningNight#start" }
DateTime EveningNightStop_Time      "Koniec wieczornej części nocy [%1$tH:%1$tM]"   <moon>     (gAstro) { channel="astro:sun:local:eveningNight#end" }


// Events
Switch DawnStart_Event              "Zdarzenie rozpoczęcia świtu" (gAstro)
Switch DayStart_Event               "Zdarzenie rozpoczęcia dnia"                          (gAstro)
Switch DuskStart_Event              "Zdarzenie rozpoczęcia zmierzchu"                             (gAstro)
Switch NightStart_Event             "Zdarzenie rozpoczęcia nocy"                            (gAstro)
Switch SunriseStart_Event           "Zdarzenie rozpoczęcia wschodu słońca" (gAstro)
Switch SunsetStart_Event            "Zdarzenie rozpoczęcia zachodu słońca" (gAstro)

// Items
Switch Dawn                         "Świt [MAP(astro.map):%s]"             (gAstro)                // After Dawn and before Day
Switch Day                          "Dzień [MAP(astro.map):%s]"            (gAstro)                  // After Day and before Dusk
Switch Dusk                         "Zmierzch [MAP(astro.map):%s]"         (gAstro)                    // After Dusk and before Night
Switch Night                        "Noc [MAP(astro.map):%s]"              (gAstro)              // After Night and before Dawn

Number SunAzimuth                   "Azymut słońca [%.0f °]"                <sun>      (gAstro) { channel="astro:sun:local:position#azimuth" }
Number SunElevation                 "Wysokość słońca [%.0f °]"              <sun>     (gAstro) { channel="astro:sun:local:position#elevation" }

String ZodiacSign                       "Znak zodiaku [MAP(astro.map):%s]"           <zodiac>             (gAstro) { channel="astro:sun:local:zodiac#sign" }
String Season                       "Pora roku [MAP(astro.map):%s]"                        (gAstro) { channel="astro:sun:local:season#name" }
String DayPhase                     "Pora dnia [MAP(astro.map):%s]"                        (gAstro) { channel="astro:sun:local:phase#name" }

String MoonPhase                    "Faza księżyca [MAP(astro.map):%s]"        <moon>        (gAstro) { channel="astro:moon:local:phase#name" }

Number      MoonElevation       "Wysokość księżyca [%.0f °]"                         <moon>   (gAstro) {channel="astro:moon:local:position#elevation"}
Number      MoonAzimuth       "Azymut księżyca [%.0f °]"                         <moon>   (gAstro) {channel="astro:moon:local:position#azimuth"}

DateTime    Moon_Next_Full       "Następna pełnia [%1$td.%1$tm.%1$tY, %1$tH:%1$tM]" <moon> (gAstro) {channel="astro:moon:local:phase#full"}
DateTime    Moon_Next_New        "Następny nów [%1$td.%1$tm.%1$tY, %1$tH:%1$tM]"  <moon>   (gAstro) {channel="astro:moon:local:phase#new"}

DateTime MoonriseStart_Time          "Początek wschodu księżyca [%1$tH:%1$tM]"   <moonrise>    (gAstro) { channel="astro:moon:local:rise#start" }
DateTime MoonriseStop_Time          "Koniec wschodu księżyca [%1$tH:%1$tM]"   <moonrise>    (gAstro) { channel="astro:moon:local:rise#end" }
DateTime MoonsetStart_Time           "Początek zachodu księżyca [%1$tH:%1$tM]"   <moonset>     (gAstro) { channel="astro:moon:local:set#start" }
DateTime MoonsetStop_Time           "Koniec zachodu księżyca [%1$tH:%1$tM]"   <moonset>     (gAstro) { channel="astro:moon:local:set#end" }

So I don’t have.

Those two warnings talking about ManagedThingProvider are concerning and might be relevant.

I also don’t see lines in the log at midnight that correspond to the Channels that represent the ones that are UNDEF.

The problem appears to be with the binding or the Thing definition. Let’s eliminate there begin something wrong with the Thing first.

Create a new Thing, this time using PaperUI, and link the UNDEF channels to some test Items. Let’s see if those Items get properly calculated. If that works, delete it and create a new one in the .things file with the same specifications as the one that you defined in PaperUI.

If those fail in the same way as your original Thing then we know that the problem isn’t necessarily with the Thing. Clear the Cache and then uninstall the Astro binding and reinstall.

If it still setting these to UNDEF, it’s time to How to file an Issue.

1 Like

Have a look at your sun/moon Things carefully in PaperUI. Even though you define them in a text .things file, I think discovery might use the :local thing name as well (to fill in from default system location) and there could be a conflict with your .things file.

1 Like

Hi,

I define in PaperUI:

astro:sun:test (Type=Thing, Status=ONLINE, Label=Astro sun data, Bridge=null)

I define item in PaperUI:

testEveningNightStart_Time (Type=DateTimeItem, State=UNDEF, Label=Początek wieczornej części nocy, Category=moon, Groups=[gAstro])

I link it to:

openhab> smarthome:links list |grep testEveningNightStart_Time
testEveningNightStart_Time -> astro:sun:test:eveningNight#start

and the value is UNDEF.

In events.log apper:

2019-05-26 21:49:31.494 [.ItemChannelLinkAddedEvent] - Link 'testEveningNightStart_Time-astro:sun:test:eveningNight#start' has been added.
2019-05-26 21:49:31.494 [vent.ItemStateChangedEvent] - testEveningNightStart_Time changed from NULL to UNDEF

The best I can recommend at this point is to file an issue at openhab2-addons. See How to file an Issue

Hi,
I have the same problem, on OH 2.5M1. I thought it was due to moving from snapshot to 2.5M1. In Paper UI:
astro
Location also Poland

I’m repeating myself but there’s no night time in Warsaw according to this link: https://www.timeanddate.com/sun/poland/warsaw

So dusk starts and dawn ends but won’t switch to night.

1 Like

Hi all,

I got the same Problems:

It’s starts with:

2019-05-23 00:00:30.337 [vent.ItemStateChangedEvent] - Night_Time_End changed from 2019-05-23T01:31:00.000+0200 to UNDEF

and on next day:

2019-05-24 00:00:30.270 [vent.ItemStateChangedEvent] - Night_Time_Start changed from 2019-05-24T01:08:00.000+0200 to UNDEF
2019-05-24 00:00:30.300 [vent.ItemStateChangedEvent] - Astro_Morning changed from 2019-05-23T01:31:00.000+0200 to UNDEF

I do nothing on my system (Openhab 2.4.005 on a synology nas) and Astro binding works fine since last year. Location is middle of Germany

I ran in similar issues. However in my case I obtain UNDEF for NauticDawn_start and NauticDusk_End. Two values which @OPeration seems to receive.
image

The reason for this seems to be for me - as @gitMiguel pointed out - that there is no “real Night” where I live :slight_smile:

There is a related issue concerning the Astro binding on github. https://github.com/openhab/openhab2-addons/issues/5006 , which seems to have a similar reason . Good to find the reason - time is tricky - and now I have to find sth clever form my rule.

BTW: I ran openHAB 2.5.0~S1558-1 (Build #1558) on raspberryPi

It is true that for some locations the (like, ASTRO_DUSK, ASTRO_DOWN, NAUTIC_DUSK, NAUTIC_DAWN, CIVIL_DUSK, CIVIL_DOWN, SUN_RISE, SUN_SET, DAYLIGHT) may be not available; just like @mdnx has mentioned, so for those events the astro library puts UNDEF, because the specific date and time can not be calculated.

@majherek, in the middle of Poland (Łódź city) around 18 May there is this thing that the ASTRO_DUSK is after the midnight of local time, so it takes place on the next dey after the sunset. However it looks to me like a bug in astri binding and the ASTRO_DUSK should be calculated correctly.

Please use https://www.heavens-above.com/sun.aspx to play around and check it by yourself. In June in Poland it gets more “complicated” as the NIGHT is never present.

@mdnx, https://github.com/openhab/openhab2-addons/issues/5006 relatetes more to the issue that sun phase name is not derived correctly, which is a bit different thing discussed in the forum topic.

1 Like

Hi,
here are sun:local:phase from log:

openhab> smarthome:links list |grep astro:sun|grep pha
DayPhase -> astro:sun:local:phase#name

openhab> smarthome:items list DayPhase
DayPhase (Type=StringItem, State=DAYLIGHT, Label=Pora dnia, Category=null, Groups=[gAstro])

And some logs:

majherek@atom:/opt/openhab/userdata/logs$ grep DayPhase  *
events.log.1:2019-06-09 20:52:00.005 [vent.ItemStateChangedEvent] - DayPhase changed from DAYLIGHT to SUN_SET
events.log.1:2019-06-09 20:52:15.588 [vent.ItemStateChangedEvent] - DayPhase changed from SUN_SET to UNDEF
events.log.1:2019-06-09 20:57:00.003 [vent.ItemStateChangedEvent] - DayPhase changed from UNDEF to CIVIL_DUSK
events.log.2:2019-06-09 21:46:00.003 [vent.ItemStateChangedEvent] - DayPhase changed from CIVIL_DUSK to NAUTIC_DUSK
events.log.2:2019-06-09 23:03:00.005 [vent.ItemStateChangedEvent] - DayPhase changed from NAUTIC_DUSK to ASTRO_DUSK
events.log.2:2019-06-10 00:00:15.587 [vent.ItemStateChangedEvent] - DayPhase changed from ASTRO_DUSK to ASTRO_DAWN
events.log.2:2019-06-10 02:10:00.006 [vent.ItemStateChangedEvent] - DayPhase changed from ASTRO_DAWN to NAUTIC_DAWN
events.log.2:2019-06-10 03:28:00.004 [vent.ItemStateChangedEvent] - DayPhase changed from NAUTIC_DAWN to CIVIL_DAWN
events.log.3:2019-06-10 04:17:00.006 [vent.ItemStateChangedEvent] - DayPhase changed from CIVIL_DAWN to SUN_RISE
events.log.3:2019-06-10 04:17:15.585 [vent.ItemStateChangedEvent] - DayPhase changed from SUN_RISE to UNDEF
events.log.3:2019-06-10 04:21:00.005 [vent.ItemStateChangedEvent] - DayPhase changed from UNDEF to DAYLIGHT
events.log.4:2019-06-10 12:37:15.584 [vent.ItemStateChangedEvent] - DayPhase changed from DAYLIGHT to NOON
events.log.4:2019-06-10 12:38:15.581 [vent.ItemStateChangedEvent] - DayPhase changed from NOON to DAYLIGHT
events.log.5:2019-06-10 20:53:00.008 [vent.ItemStateChangedEvent] - DayPhase changed from DAYLIGHT to SUN_SET
events.log.5:2019-06-10 20:53:15.587 [vent.ItemStateChangedEvent] - DayPhase changed from SUN_SET to UNDEF
events.log.5:2019-06-10 20:58:00.004 [vent.ItemStateChangedEvent] - DayPhase changed from UNDEF to CIVIL_DUSK
events.log.5:2019-06-10 21:46:00.005 [vent.ItemStateChangedEvent] - DayPhase changed from CIVIL_DUSK to NAUTIC_DUSK
events.log.5:2019-06-10 23:04:00.008 [vent.ItemStateChangedEvent] - DayPhase changed from NAUTIC_DUSK to ASTRO_DUSK
events.log.5:2019-06-11 00:00:15.588 [vent.ItemStateChangedEvent] - DayPhase changed from ASTRO_DUSK to ASTRO_DAWN
events.log.6:2019-06-11 02:09:00.003 [vent.ItemStateChangedEvent] - DayPhase changed from ASTRO_DAWN to NAUTIC_DAWN
events.log.6:2019-06-11 03:27:00.004 [vent.ItemStateChangedEvent] - DayPhase changed from NAUTIC_DAWN to CIVIL_DAWN
events.log.6:2019-06-11 04:16:00.008 [vent.ItemStateChangedEvent] - DayPhase changed from CIVIL_DAWN to SUN_RISE
events.log.6:2019-06-11 04:16:15.585 [vent.ItemStateChangedEvent] - DayPhase changed from SUN_RISE to UNDEF
events.log.6:2019-06-11 04:21:00.004 [vent.ItemStateChangedEvent] - DayPhase changed from UNDEF to DAYLIGHT
events.log.7:2019-06-11 12:37:15.586 [vent.ItemStateChangedEvent] - DayPhase changed from DAYLIGHT to NOON
events.log.7:2019-06-11 12:38:15.586 [vent.ItemStateChangedEvent] - DayPhase changed from NOON to DAYLIGHT

There are transitions with UNDEF:

SUN_SET -> UNDEF -> CIVIL_DUSK
SUN_RISE -> UNDEF -> DAYLIGHT

And In my example the problem was that from 19th od May there is no night in Warsaw :wink:

There is a bug inside of astro binding related to the transition from above. I have already proposed a pull request with the fix. At tleast this kind of issue will be fixed.

Other thing reported:

This I would not consider as a bug since at this time in Warsaw there is no night, so we can consider UNDEF as a information that the night is not present at this place on this specific time. However UNDEF may be a bit confusing, so the user can think that there is some kond of error inside of astro binding and astro has some problems with calculating the correct time. If astro give us the state like NOT_PRESENT, then we could now that astro knows how to correctly calculate the date/time and it knows that at this particular place on a specific time, the night is not present, so it will show to us NOT_PRESENT instead od UNDEF. That would be a small improvement. What do you think?

However this:

I would consider as a bug in astro binding. If the binding is able to calculate the AstroDawnStop_Time then it should be also to be able to calculate correctly the AstroDawnStart_Time.

Hi,

Great that you wrote fix. But the Travis CI build failed.

I think that is good idea. UNDEF for me, mean something wrong :wink: NOT_PRESENT is more natural.

I don’t think it is a bug.
Look at https://www.timeanddate.com/sun/poland/warsaw on e.g. 26 of May. The dusk start at evening of 25 and it doesn’t stop till midnight (so it can stop at 24:00). And on 26 of May the Dawn stop at the morning, but never start (so it can start at 00:00). Astronomical Twilight is from: 00:00 - 02:35 and from 22:32 - 00:00.
It also should be NOT_PRESENT, not UNDEF.

Build fails because there is something wrong with Smartmeter Binding 2.5.0-SNAPSHOT. You need to take a closer look into build log to find out. It looks like Travis builds all bindings together.

Ok, I will take a look at this and go back to you later.

UNDEF is explicitly supposed to be used in this sort of situation. UNDEF essentially means NOT_PRESENT. I think a sentence added to the README to explain what it means when one sees UNDEF would be more appropriate (and easier to get approved) than adding a new special State type to the core, especially since that new State type is already supposed to be covered by the existing UNDEF. Adding NOT_PRESENT or replacing NOT_PRESENT with UNDEF will require changes to the OH core and will ripple out to several other bindings, so the change cannot be taken lightly.

The main reason why UNDEF is confusing to some users is it isn’t used all that much by the bindings. But I’m happy to see more and more bindings use it just like Astro does, to indicate that there is no State or the State cannot be known (e.g. when the MQTT Broker Thing goes offline, all of the Channels that use that Broker go to UNDEF to indicate we have no way to know the current states).

1 Like