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