Astro binding fires sunrise events at midnight

Hi all,
I’m using the latest stable version of OH2 and the astro binding 2.4.0. It’s installed like the samples of the binding.

Things:

astro:sun:home [ geolocation=“48.433494, 10.413728”, interval=600]
astro:moon:home [ geolocation=“48.433494, 10.413728”, interval=600]

Items:

DateTime Sunrise_Time “Sonnenaufgang[%1$tH:%1$tM]” { channel=“astro:sun:home:rise#start” }
DateTime Sunset_Time “Sonnenuntergang [%1$tH:%1$tM]” { channel=“astro:sun:home:set#start” }
String MoonPhase “Mondphase [MAP(astro.map):%s]” { channel=“astro:moon:home:phase#name” }
DateTime Daylight_End “Tageslicht Ende [%1$tH:%1$tM]” { channel=“astro:sun:home:daylight#end” }

rule:

rule “Sonnenuntergang”
when
Channel ‘astro:sun:home:set#event’ triggered END

then
Steckdose_5_Power.sendCommand(1)
Steckdose_6_Power.sendCommand(1)
end

Log:

2019-06-20 00:00:30.134 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:moon:home
2019-06-20 00:00:30.195 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:home

2019-06-21 00:00:32.659 [vent.ChannelTriggeredEvent] - astro:sun:home:set#event triggered START
2019-06-21 00:00:32.668 [vent.ChannelTriggeredEvent] - astro:sun:home:daylight#event triggered END
2019-06-21 00:00:32.674 [vent.ChannelTriggeredEvent] - astro:sun:home:set#event triggered END
2019-06-21 00:00:32.678 [vent.ChannelTriggeredEvent] - astro:sun:home:civilDusk#event triggered START
2019-06-21 00:00:32.783 [vent.ChannelTriggeredEvent] - astro:sun:home:civilDusk#event triggered END
2019-06-21 00:00:32.789 [vent.ChannelTriggeredEvent] - astro:sun:home:nauticDusk#event triggered START
2019-06-21 00:00:33.007 [vent.ChannelTriggeredEvent] - astro:sun:home:astroDusk#event triggered START
2019-06-21 00:00:33.011 [vent.ChannelTriggeredEvent] - astro:sun:home:nauticDusk#event triggered END
2019-06-21 00:00:33.109 [vent.ChannelTriggeredEvent] - astro:moon:home:rise#event triggered START

As you can see, all the events are fired at midnight. For my reference I checked the state of the Sunrise Start and it shows correct 21:21. The clock of the Raspberry is also correct. Other cron jobs are correct too.

I tried the Things installed through PaperUI too no change. Reinstalling of the binding didn’t help.

Any ideas?
Thanks / Zennix

Check what time you get in your items (e.g. Sunset_Time). Also check your regional settings (PaperUI -> Configurtaion -> System). I had the issue, that OpenHab was using the wrong time-zone, so in the logs the time was wrong. If I remember correctly, I had to add “-Duser:timezone=Europe/Madrid” in “start_runtime.sh”.

Thank you,
Location and time in the logs are correct.

Daylight end and sunset shows correct time.

Greetings / Zennix

I’ve never seen anything quite like that with standard OH 2.4.0
It looks like weird coordinates behaviour.

The job schedule at 30 secs past midnight is normal.

Did you use the same names here? That can result in conflict between xxx.things file versions and PaperUI versions. Some obscure problem from file (like wrong quote marks) could still be lurking.

A suggestion - create new named things in PaperUI to test e.g.
astro:sun:myhome

Thank you,

the thing created in PaperUI was named astro:sun:local, things created through astro.things astro:sun:home, so it was different.
Amazing that the moon events are fired correctly.

2019-06-23 17:50:39.783 [vent.ChannelTriggeredEvent] - astro:moon:home:rise#event triggered START

Greetings / Zennix

So, the set of events from file based thing was in error, but the PaperUI was not.
Suspect things file e.g. character set, what do you use to edit?

Some moon events

2019-06-21 00:00:33.109 [vent.ChannelTriggeredEvent] - astro:moon:home:rise#event triggered START

Hi,
Next try, doing all with PaperUI:

rm /etc/oipenhab2/things/astro.things
rm /etc/openhab2/items/astro.items
remove astro binding through PaperUI
systemctl stop openhab2.service
rm /var/lib/openhab2/tmp/* -r
rm /var/lib/openhab2/cache/* -r
systemctl start openhab2.service
wait long to be sure it’s finished
Install Astro Binding with PaperUI
Add both things from inbox
From Configuration - Things - Lokale Sonnendaten - create Item “LokaleSonnendaten_Set_Startzeit”
In HABPanel create dummy widget and add LokaleSonnendaten_Set_Startzeit Format HH:mm
grafik

Wait till tomorrow.

Greetings / Zennix

2019-06-26 00:00:32.535 [vent.ChannelTriggeredEvent] - astro:sun:local:daylight#event triggered END
2019-06-26 00:00:32.540 [vent.ChannelTriggeredEvent] - astro:sun:local:set#event triggered START
2019-06-26 00:00:32.545 [vent.ChannelTriggeredEvent] - astro:sun:local:civilDusk#event triggered START
2019-06-26 00:00:32.550 [vent.ChannelTriggeredEvent] - astro:sun:local:set#event triggered END
2019-06-26 00:00:32.556 [vent.ChannelTriggeredEvent] - astro:sun:local:nauticDusk#event triggered START
2019-06-26 00:00:32.565 [vent.ChannelTriggeredEvent] - astro:sun:local:civilDusk#event triggered END
2019-06-26 00:00:32.569 [vent.ChannelTriggeredEvent] - astro:sun:local:nauticDusk#event triggered END
2019-06-26 00:00:32.572 [vent.ChannelTriggeredEvent] - astro:sun:local:astroDusk#event triggered START

Nothing changed.

Well it doesn’t happen for other people.
I’m struggling to think what can influence this outside of polar locations.
As you are using your system defaults now, may we see the values of your discovered Astro Things? (PaperUI - Configuration - Things - Local Sun - Edit)

Can you confirm that you are running plain ordinary OH 2.4 release?

Thank you,
Yes I’m using a plain stable 2.4 OH2 version.

Not the Arctic. Got me beaten, I see nothing odd there.

There can be date weirdness running jobs at exactly midnight - but your Astro version is clearly running with the fix, 30 seconds past midnight.

There is an outstanding Astro issue about locations outside of system time zone / locale. But this does not seem to a very good fit to your symptoms.

I have thought of something - range events earliest/latest modifiers. If these have got inadvertently set to 00:00 or something (the kind of thing that might happen when trying to clear entries in PaperUI) it might cause this effect.

Once again I would suggest starting with a completely new named sun Thing (so that it cannot pick up any cached ranges etc.) for a trial.

Hi Thomas,
in your Example-Things-File above, the Quotation Marks are in a wrong version

Yours:

astro:sun:home [ geolocation=“48.433494, 10.413728”, interval=600]
astro:moon:home [ geolocation=“48.433494, 10.413728”, interval=600]

should look like:

astro:sun:home [ geolocation="48.433494, 10.413728", interval=600]
astro:moon:home [ geolocation="48.433494, 10.413728", interval=600]

Another problem could be, that your File has not the correct format (UTF-8).

Third point (i don’t know if it’s necessary) i’m using the spelling with “Thing”, like here:

//    Astro - Binding Geo-Position  geolocation="xx..xxxxxx,y.yyyyy,zzz"

Thing astro:sun:local     "Sonnen Daten"    [geolocation="xx..xxxxxx,y.yyyyy,zzz", interval=300]
Thing astro:moon:local    "Mond Daten"      [geolocation="xx..xxxxxx,y.yyyyy,zzz", interval=300]

Maybe this helps you.

Cheers
Peter

EDIT: All Qoutation Marks are wrong :wink::wink:

@ Peter
The actual config is completly without config files. Only created through PaperUI.
So, that can’t be the problem.

@rossko57
At midnight ther are a lot of events coming from openweather binding. I will try to deactivate this.
I will give it a new try to create it again with completly different names.

Thanks / Thomas

As @rossko57 said, there is a problem, when using other Geo-Positions in your Things-File, than in your Default-Parameters defined in your PaperUI. Your settings are different there.

Hi Peter,
thank you.
The next try is to configure all within config files with unique thing names. I will set the coordinates equal to the system settings, thanks. Also I will deactivate openweather binding.
I will report tomorrow.
Greetings Zennix

Hi all,
unfortunately same results.

2019-06-27 00:00:30.205 [vent.ItemStateChangedEvent] - Sonnenaufgang changed from 2019-06-26T05:19:00.000+0200 to 2019-06-27T05:20:00.000+0200
2019-06-27 00:00:30.256 [vent.ItemStateChangedEvent] - Sonnenuntergang changed from 2019-06-26T21:21:00.000+0200 to 2019-06-27T21:21:00.000+0200
2019-06-27 00:00:30.263 [vent.ItemStateChangedEvent] - Tageslichtende changed from 2019-06-26T21:21:00.000+0200 to 2019-06-27T21:21:00.000+0200
2019-06-27 00:00:31.600 [vent.ChannelTriggeredEvent] - astro:sun:burgau:set#event triggered START
2019-06-27 00:00:31.604 [vent.ChannelTriggeredEvent] - astro:sun:burgau:daylight#event triggered END
2019-06-27 00:00:31.634 [vent.ChannelTriggeredEvent] - astro:sun:burgau:set#event triggered END
2019-06-27 00:00:31.640 [vent.ChannelTriggeredEvent] - astro:sun:burgau:civilDusk#event triggered START
2019-06-27 00:00:31.808 [vent.ChannelTriggeredEvent] - astro:sun:burgau:civilDusk#event triggered END
2019-06-27 00:00:31.812 [vent.ChannelTriggeredEvent] - astro:sun:burgau:nauticDusk#event triggered START
2019-06-27 00:00:32.065 [vent.ChannelTriggeredEvent] - astro:sun:burgau:astroDusk#event triggered START
2019-06-27 00:00:32.069 [vent.ChannelTriggeredEvent] - astro:sun:burgau:nauticDusk#event triggered END

I will stop now further investigations. Astro binding is not made for me. Looking for another solution to get the lights on.
Thanks to all.

Greetings / Zennix

Fair enough; the new thing name rules out picking up any old range conditions.

There is some mysterious circumstance in your system somewhere, but reinstalling the whole show is not a reasonable try-it-and-see.

I feel a photosensor coming … :wink:

Hello, I have exactly the same problem since few days. At 00:00:32 I receive the event of sunset end. Astro binding has been working for 1 year more or less. I did not change anything. Maybe the Raspberry was rebooted because power fails but I think this was after the problem.

Hi,

the same problem here. Astro binding installed and configured through PaperUI. Openhab 2.4. The DateTime values for day start and day end are correctly set (according to the location), but all astro:sun:events are fired at 00:00:30.
Any idea where to look and what to change?

Kind regards,
Michael

Hi,
There is no replay from the developer. I checked a lot without any success. Now I solved it for me with a timer in a rule counting from the information from correctly set sun rise time.

Greeting / Zennix