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

Tags: #<Tag:0x00007f387895d550> #<Tag:0x00007f387895d410>

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.

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. , 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 to play around and check it by yourself. In June in Poland it gets more “complicated” as the NIGHT is never present.

@mdnx, 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

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:


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.


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 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).

That’s just a matter of interpreting the language used. UNDEF stands for undefined, not for error. It can mean error, but it can also mean can’t calculate that, as in “what weekday is 29th Feb this year?” and it can mean “I can’t get that data at this time” because a device is busy.

Do you mean astro docs?

Yes, that is what I mean.

The definition of UNDEF comes from the OpenHAB Core library. Here is how it is commented in the code:

 * There are situations when item states do not have any defined value.
 * This might be because they have not been initialized yet (never
 * received an state update so far) or because their state is ambiguous
 * (e.g. a dimmed light that is treated as a switch (ON/OFF) will have
 * an undefined state if it is dimmed to 50%).

My impression about UNDEF - in general - is that the value is undefined. But we do not know what is the root caus of this. It may be as stated in the astro docs:

But it also may be a result of a bug inside of astro - just like in case of reported #5006 issue. Another thing is when OpenHAB service is during startup and the state of thing is really undefined yet.

I have the feeling that Astro should never deliver UNDEF, because every status/phase/range can be well known by doing a correct calculations, so the state that NIGHT is not present could be indicated by something different than UNDEF.
For now we can also live with UNDEF but it would be good eliminate as much of those as we can.

@majherek, thanks for the link to this online datetime calulator. I have took a look at th 19th and 20th of May in Warsaw and I have prepared the table of what states/ranges should generate Astro binding to coved those two days correctly (in my opinion):

   ASTRO_DUSK = 19th May 00:12 -> 19th May 00:12		
        NIGHT = 19th May 00:12 -> 19th May 00:51
EVENING_NIGHT = 19th May 00:12 -> 19th May 00:32 (NOON + 12h)
MORNING_NIGHT = 19th May 00:32 -> 19th May 00:51
   ASTRO_DAWN = 19th May 00:51 -> 19th May 02:51
  NAUTIC_DAWN = 19th May 02:51 -> 19th May 03:52
   CIVIL_DAWN = 19th May 03:52 -> 19th May 04:35
     SUN_RISE = 19th May 04:35 -> 19th May 04:35
     DAYLIGHT = 19th May 04:35 -> 19th May 20:29
	 NOON = 19th May 12:32
      SUN_SET = 19th May 20:29 -> 19th May 20:29
   CIVIL_DUSK = 19th May 20:29 -> 19th May 21:13
  NAUTIC_DUSK = 19th May 21:13 -> 19th May 22:15
   ASTRO_DUSK = 19th May 22:15 -> 20th May 00:00
   ASTRO_DUSK = 20th May 00:00 -> 20th May 00:32 (NOON + 12h)  
   ASTRO_DAWN = 20th May 00:32 -> 20th May 02:49
  NAUTIC_DAWN = 20th May 02:49 -> 20th May 03:50
   CIVIL_DAWN = 20th May 03:50 -> 20th May 04:34
     SUN_RISE = 20th May 04:34 -> 20th May 04:34
     DAYLIGHT = 20th May 04:34 -> 20th May 20:31	 
	 NOON = 20th May 12:32	 
      SUN_SET = 20th May 20:31 -> 20th May 20:31
   CIVIL_DUSK = 20th May 20:31 -> 20th May 21:15	  
  NAUTIC_DUSK = 20th May 21:15 -> 20th May 22:17
   ASTRO_DUSK = 20th May 22:17 -> 21th May 00:00  

Astro calculates a sun rise/set as a range with about 4 minutes duration (not included above). I have also use NOT_PRESENT in the example. With this representation all of the ranges will be consistent with the astronomical events. Unfortunately Astro binding is not able to deliver two ASTRO_DUSK events/ranges for the specific date (there a two ASTRO_DUSKs at 20th May 2019 in Warsaw). I do not know how can it be “fixed”. One of the option could be to deliver the closesd range/event, so between midnight and noon astro will devliver

   ASTRO_DUSK = 20th May 00:00 -> 20th May 00:32 (NOON + 12h)

and after the noon it will deliver

   ASTRO_DUSK = 20th May 22:17 -> 21th May 00:00

What do you think guys?

Opposite opinion from me. If there is no sunrise today then today’s sunrise time is not defined. UNDEF is entirely appropriate,

Barring genuine bugs, there is no other reason for Astro to set UNDEF than this kind of situation. Adding some other new state (which would have to affect all Items of DateTime state, right across openHAB), some new state like NOT_PRESENT doesn’t add any information. Whether it says UNDEF or NOT_PRESENT you know what it means - there’s no answer for that question today.

If it’s not been calculated yet after start up, it will be NULL. The description from core is a bit misleading here - Items are created NULL and stay that way until updated by some action.

The fact that something may get set to UNDEF due to some bug is not I think relevant. A bug could just as well cause unexpected setting of NOT_PRESENT or 23:59 1/1./2099. A bug is a bug, an erroneous value is an erroneous value.

Thanks for clarification around this NULL value. However I have read this topic again and I see that @rlkoshak has also explained this before. Sorry - my bad.

Yes, I need to agree with this.

@rossko57, so you propose something like this: in Astro binding UNDEF means that the specific event/phase/range/date/time is not present at the specific date and location. Other words if night_startTime is UNDEF, then it means that there is no night at the specific time and place. This would be also backward compatible so there will be no need to update the rules in the openHAB system. I can understand this point of view.
So now - with this aproach - we confirmed that Astro binding can return UNDEF for some specific channel, which - under some specific conditions (like high latitude locationas at the June doesn’t have NIGHT) - is an expected behavior. Unless somebody says, that for his location at this specific date the date of event is wrongly calculated, which should be treated as a bug (then it should be fixed in Astro binding).

1 Like

:+1: I completely agree. If there is no such time today, then UNDEF is completely appropriate. There is nothing about the state UNDEF that implies the Item is UNDEF because of some sort of problem. Nor should there be IMHO. If we don’t know the state of a Channel, the Channel is in an undefined state. There are other ways to determine if there is something wrong (e.g. the Offline state for Channels).

If an Item gets set to UNDEF erroneously has no bearing on the argument for the inclusion of a new NOT_PRESENT state.

There is already enough confusion on the difference between UNDEF and NULL where the distinction is pretty clear cut. The distinction between UNDEF and NOT_PRESENT is going to be much too subtle and it will cause a ton of confusion for users.

I do agree, if a Channel is calculable by Astro that Channel should have a valid state. But if it isn’t then UNDEF is the proper state.

Don’t apologise, it’s useful to air these things.
I think the NULL / UNDEF distinction was not nearly as clear cut in OH1 (where we had Undefined instead) and there may be woolly comments like the one you found that come from that historical background.

Great question Witold and great discussion gentlemen

And of course you can test for UNDEF in a rule with an if statement and have your interface of choice display whatever you want under those conditions

Ok, so the UNDEF variable is for now clarified.

I have just one question to clarify. Please go back to my previous post where I have put an example of all phases on 19th and 20th May in Warsaw. There are two ASTRO_DUSKs (one right after the midnight on 19th May, second right before midnight of the same day) ranges at those days. Astro binding can only provide one ASTRO_DUSK range at the time. Which one should be provided?
And second thing: if some specific range overlaps the midnight, then what should provide Astro? For example there is the following Astro Dusk

19th May 22:15 -> 20th May 00:32

So for example on the 19th May 2019, what should Astro provide:
the full range
ASTRO_DUSK = 19th May 22:15 -> 20th May 00:32
or truncated to midnight range
ASTRO_DUSK = 19th May 22:15 -> 20th May 00:00
or UNDEF as the astro dusk doesn’t end at th 19th May
ASTRO_DUSK = 19th May 22:15 -> UNDEF
Looks like always truncates the date/time to midnight.

Good point. No idea what can be done about that.
There’s only one of each static channel type. So let’s populate that with the next event, just after midnight.
When Astro next recalculates at midnight - it will have already missed the second one for what is now the previous day.

A dirty fix might be to have it recalculate at noon as well as midnight.

Not sure what you mean here; do you mean the phase name string channel? That really just tells you what the last event was out of a set of particular events. e.g. ASTRO_DAWN, NAUTIC_DAWN, CIVIL_DAWN …

I would say sun phase name would change to ASTRO_DUSK at 19th May 22:15, there would be no NIGHT phase today I think?, then change to ASTRO_DAWN at 20th May 00:32