Openhab-addons: [astro] Sun Phase returns UNDEF

[bennybubble]

The ASTRO binding in OH 2.4 returns UNDEF at certain time

Expected Behavior

It should not return UNDEF but either the previous of next phase

Current Behavior

2019-02-27 18:14:00.046 [vent.ItemStateChangedEvent] - PeriodOfDay changed from DAYLIGHT to SUN_SET
2019-02-27 18:14:36.377 [vent.ItemStateChangedEvent] - PeriodOfDay changed from SUN_SET to UNDEF
2019-02-27 18:18:00.031 [vent.ItemStateChangedEvent] - PeriodOfDay changed from UNDEF to CIVIL_DUSK
2019-02-27 18:52:00.026 [vent.ItemStateChangedEvent] - PeriodOfDay changed from CIVIL_DUSK to NAUTIC_DUSK
2019-02-27 19:31:00.035 [vent.ItemStateChangedEvent] - PeriodOfDay changed from NAUTIC_DUSK to ASTRO_DUSK
2019-02-27 20:10:00.034 [vent.ItemStateChangedEvent] - PeriodOfDay changed from ASTRO_DUSK to NIGHT
2019-02-28 05:40:00.033 [vent.ItemStateChangedEvent] - PeriodOfDay changed from NIGHT to ASTRO_DAWN
2019-02-28 06:19:00.041 [vent.ItemStateChangedEvent] - PeriodOfDay changed from ASTRO_DAWN to NAUTIC_DAWN
2019-02-28 06:58:00.053 [vent.ItemStateChangedEvent] - PeriodOfDay changed from NAUTIC_DAWN to CIVIL_DAWN
2019-02-28 07:32:00.027 [vent.ItemStateChangedEvent] - PeriodOfDay changed from CIVIL_DAWN to SUN_RISE
2019-02-28 07:32:36.367 [vent.ItemStateChangedEvent] - PeriodOfDay changed from SUN_RISE to UNDEF
2019-02-28 07:36:00.028 [vent.ItemStateChangedEvent] - PeriodOfDay changed from UNDEF to DAYLIGHT

First line is initialization, next are generated when SUN Phase changes state.

Possible Solution

Don't know, not experienced JAVA programmer to solve this

Steps to Reproduce (for Bugs)

Add item

String PeriodOfDay  "Period of Day [%s]" {channel="astro:sun:home:phase#name"}

Execute rule and check log file

rule "Sun Phase"
when
    Item PeriodOfday changed
then
    logInfo("astro.rules",PeriodOfDay.state.toString)
end

Context

Your Environment

• OH2.4
• Astro binding 2.4
• RPI Raspbian Jessie
• I'm located in the Netherlands so I face all phases ... :-)

[wmarkow]

If you do not mind, I can take a look at this issue. At least I'm able to reproduce it.

[martintamke]

Hello @wmarkow - thanks for looking into this. The reason why the UNDEF appear might be, that in summer month certain types of sunsets do not appear (Nautic ones e.g.)
there is a running discussion of related issues on the openHAB forum .

The conclusion here is to look into Time and Date - whether the event actually occurs at the Local. (I have an issue with Nautic Dawn- and voilà it doesn't occur, were I live - :-) - a need to reprogram my rule.

[wmarkow]

A short info how to reproduce the original issue:

• prepare Eclipse installation with the soources of org.openhab.demo.app and org.openhab.binding.astro as described in https://www.openhab.org/docs/developer/ide/eclipse.html
• in /org.openhab.demo.app/runtime/logback.xml file change the logging level from WARN to INFO

 <root level="INFO">
    <appender-ref ref="STDOUT" />
  </root>

so you can see more information in console

• from Eclipse start the OpenHAB application
• in the Internet Browser navigate to http://localhost:8080, add the Astro Sun Data thing from Astro Binding, configure your location to Amsterdam, set the thing interval to be 15 second
• change the computer date to be 27 Feb 2019
• put a conditional breakpoint at the end of org.openhab.binding.astro.internal.calc.SunCalc.getSunInfo(Calendar, double, double, Double, boolean) method with the following condition sun.getPhase().getName() == null
• wait around 15 second so your thing will be queried by the system for data. Inspect the console output in Eclipse to learn for Sun set event:

[safeCall-2] INFO  smarthome.event.ItemStateEvent:53 - astro_sun_8c2f8c23_set_start updated to 2019-02-27T18:12:00.000+0100

• so the sun set in AMsterdam at 27 Feb 2019 is at 18:12:00. Change the clock on your computer to 18:10 restart quickly the application in Eclipse and wait for the breakpoint to hit. Now you can inspect why the phase is UNDEF (or actually it is null).

[wmarkow]

At the end of org.openhab.binding.astro.internal.calc.SunCalc.getSunInfo(Calendar, double, double, Double, boolean) method there is a piecie of code which tries to derive the current sun phase from the list of the ranges:

MORNING_NIGHT=Range[start=Wed Feb 27 00:00:00 CET 2019,end=Wed Feb 27 05:40:00 CET 2019]
NIGHT=Range[start=Wed Feb 27 20:09:00 CET 2019,end=Thu Feb 28 05:38:00 CET 2019]
NOON=Range[start=Wed Feb 27 12:55:00 CET 2019,end=Wed Feb 27 12:56:00 CET 2019]
CIVIL_DAWN=Range[start=Wed Feb 27 06:59:00 CET 2019,end=Wed Feb 27 07:34:00 CET 2019]
EVENING_NIGHT=Range[start=Wed Feb 27 20:09:00 CET 2019,end=Thu Feb 28 00:00:00 CET 2019 
ASTRO_DAWN=Range[start=Wed Feb 27 05:40:00 CET 2019,end=Wed Feb 27 06:20:00 CET 2019]
ASTRO_DUSK=Range[start=Wed Feb 27 19:29:00 CET 2019,end=Wed Feb 27 20:09:00 CET 2019]
CIVIL_DUSK=Range[start=Wed Feb 27 18:16:00 CET 2019,end=Wed Feb 27 18:50:00 CET 2019]
NAUTIC_DUSK=Range[start=Wed Feb 27 18:50:00 CET 2019,end=Wed Feb 27 19:29:00 CET 2019]
NAUTIC_DAWN=Range[start=Wed Feb 27 06:20:00 CET 2019,end=Wed Feb 27 06:59:00 CET 2019]
DAYLIGHT=Range[start=Wed Feb 27 07:37:00 CET 2019,end=Wed Feb 27 18:12:00 CET 2019]

Obviously it will always fail (result with UNDEF) on SUN_SET or SUN_RISE, because those ranges are missing on the list above. That's why the astro binding is not able to set a correct phase (SUN_RISE or SUN_SET). This is a bug inside of astro.

I will shortly propose a fix for this case.