I had posted my issues with the Astro binding scheduler here . In the meantime I cleaned up all links from old configs as suggested, created a new channel, items and rules.
The result is that now:
the channels only fire on the day I started OH2, but nothing after midnight (e. g. nautic dawn, civil dawn), although event jobs get scheduled
As everything was working for months up until I switched to build 983 from 885 I assume the changed made to the scheduler broke the binding. Is there a way to get the last working version of the binding back?
I’m current on OH 2.2, build #988. I freshly installed the Astro binding when I was on build #986 (so with the new ESH version). And made all the settings.
I have the following rule:
rule "Zonsondergang - nachtverlichting aan"
when
Channel 'astro:sun:local:set#event' triggered START
then
logInfo("Astro","De zon gaat onder. Slaapwel.")
sendCommand(KNX_GV_Nachtverlichting_4_2_0, ON)
end
Sounds familiar. Did a fresh install of the system, build #988 yesterday as well (including moving all the zwave stuff )
Started the system and all astro item initialized correctly.
16:12:04.507 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:home
16:12:04.514 [INFO ] [marthome.event.ItemStateChangedEvent] - Sunrise_Time changed from NULL to 2017-07-20T06:04:00.000-0500
16:12:04.517 [INFO ] [marthome.event.ItemStateChangedEvent] - Sunset_Time changed from NULL to 2017-07-20T19:53:00.000-0500
16:12:04.521 [INFO ] [marthome.event.ItemStateChangedEvent] - NauticDawn_Time changed from NULL to 2017-07-20T05:05:00.000-0500
16:12:04.524 [INFO ] [marthome.event.ItemStateChangedEvent] - CivilDawn_Time changed from NULL to 2017-07-20T05:38:00.000-0500
16:12:04.527 [INFO ] [marthome.event.ItemStateChangedEvent] - NauticDusk_Time changed from NULL to 2017-07-20T20:23:00.000-0500
16:12:04.529 [INFO ] [marthome.event.ItemStateChangedEvent] - CivilDusk_Time changed from NULL to 2017-07-20T19:56:00.000-0500
Then the channels fired yesterday evening as expected, i. e. civil dusk, nautical dusk:
No wonder nothing happens after midnight.
So I guess once we have a change of date the scheduler doesn’t work correctly any more, which renders the binding useless for the time being.
So it seems that the scheduler indeed uses the current day (the one before midnight at the time of scheduling), and not the next day (2017-07-22).
That would at least explain why the dawn events do not fire at all.
This evening at 19:55 Civil Dawn should have fired and turned on the lights, as expected nothing happened.
For one day the scheduler on midnight generated thiese messages:
23:59:57.426 [INFO ] [marthome.event.ItemStateChangedEvent] - NauticDusk_Time changed from 2017-07-21T20:22:00.000-0500 to 2017-07-22T20:22:00.000-0500
23:59:57.427 [INFO ] [marthome.event.ItemStateChangedEvent] - CivilDusk_Time changed from 2017-07-21T19:55:00.000-0500 to 2017-07-22T19:55:00.000-0500
00:00:00.015 [INFO ] [marthome.event.ItemStateChangedEvent] - Sunrise_Time changed from 2017-07-22T06:06:00.000-0500 to 2017-07-23T06:06:00.000-0500
00:00:00.016 [INFO ] [marthome.event.ItemStateChangedEvent] - Sunset_Time changed from 2017-07-22T19:52:00.000-0500 to 2017-07-23T19:52:00.000-0500
00:00:00.016 [INFO ] [marthome.event.ItemStateChangedEvent] - NauticDawn_Time changed from 2017-07-22T05:07:00.000-0500 to 2017-07-23T05:07:00.000-0500
00:00:00.017 [INFO ] [marthome.event.ItemStateChangedEvent] - CivilDawn_Time changed from 2017-07-22T05:39:00.000-0500 to 2017-07-23T05:39:00.000-0500
00:00:00.017 [INFO ] [marthome.event.ItemStateChangedEvent] - NauticDusk_Time changed from 2017-07-22T20:22:00.000-0500 to 2017-07-23T20:21:00.000-0500
00:00:00.017 [INFO ] [marthome.event.ItemStateChangedEvent] - CivilDusk_Time changed from 2017-07-22T19:55:00.000-0500 to 2017-07-23T19:54:00.000-0500
Note that the times for the new day are correct.
This led me to believe that there respective rules would finally be triggered - unfortunately, nothing happened again.
The following day midnight the job only logged the usual
On my side it seems that the trigger is working for exactly 7 Days after that, the binding stop triggering. I install a new system on 04.07. first time it stops on 11.07.
I restart the system on 20.07. without any changes. and the trigger was working again to yesterday, it stops again. Today I restart again and will see if the trigger is working tomorrow…
Is there any solution? With this status the astro binding is useless!
Same for me.
It is stopping after some days. After restarting OH (2.1) it is fine for some days and is stopping to trigger the events again.
I do use mainly triggers with offsets to the normal sunset (-60 Min & +20 Min).
I can find a lot of the following error in the log file
2017-08-09 00:00:00.610 [ERROR] [thome.binding.astro.internal.job.Job] - Queue full
java.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(AbstractQueue.java:98)[:1.8.0_131]
at org.eclipse.smarthome.binding.astro.handler.AstroThingHandler.addJobToQueue(AstroThingHandler.java:314)[410:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at org.eclipse.smarthome.binding.astro.internal.job.Job.schedule(Job.java:58)[410:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at org.eclipse.smarthome.binding.astro.internal.job.Job.scheduleEvent(Job.java:94)[410:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at org.eclipse.smarthome.binding.astro.internal.job.Job.scheduleRange(Job.java:114)[410:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at org.eclipse.smarthome.binding.astro.internal.job.DailyJobSun.run(DailyJobSun.java:64)[410:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_131]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_131]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_131]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Actually the “Queue full” error was fixed more than four weeks ago, are you sure you are running a recent astro binding ?
(and maybe also a recent 2.2 snapshot runtime is needed):
I think different type issues are discussed in this thread. In my post, I didn’t mention the Queue full error message. It is just that the Channel ‘astro:sun:local:set#event’ does not get triggered.
I have created an issue for this:
If others have the same problem, feel free to add additional information. I wasn’t sure what other information could be relevant.
Oh. I was not aware. As mentioned before, I am using the stable release 2.1.
Good to know that this bug was fixed, but as this bug was fixed after the stable release, people like me who try to use stable (suggest more tested and reliable) releases for their production environment, this is not perfect
I will try to use the latest binding from 2.2 and see if this helps.
I have the same issue and can now re-produce it.
I’m using OH 2.2.0-SNAPSHOT Build #1020.
Everything works fine until I do a reboot of the system. Could be, that the same behavior can be seen after restarting the service. The schedule for the current day is fine but at midnight the schedule job for astro:sun:local thing is not triggered. You can see this in the log file as well. Only “moon” is logged.
After clearing all things, links and items in the console, re-start of OH2.2 and manually adding the things moon and sun in the paper UI, it’s working correct again.
I think you are asking when OpenHAB 2.2 will be released. I don’t think that this has been decided (or made public). It could be days, weeks or even months.
If you don’t like that uncertainty, you can indeed switch to the snapshots (despite the fact they are snapshots, I can’t say they are less stable). Alternatively, read this post. You could add the newer Astro-JAR to your current OpenHAB 2.1 installation.