On the one day I get all triggers and the next day I do not get some triggers anymore - also not in the eventlog…
I already configured my rasparry to reboot three times a week to fix the problem (after a reboot everything seems to be going well).
Question 1: Does anyone know a solution to the problem?
Question 2: How can I rebuild the rule to use the sunset time as a trigger? The time is 99% available even if I receive no trigger…
rule "Sunset"
when
Channel 'astro:sun:myhome:set#event' triggered START
then
....
end
astro:sun:home [ geolocation="xxxxxxxxxxxxxxxxxxx", interval=320]
astro:moon:home [ geolocation="xxxxxxxxxxxxxxxxxxx", interval=280]
astro:sun:myhome [ geolocation="xxxxxxxxxxxxxxxxxxx", interval=240 ] {
Channels:
Type rangeEvent : set#start [
earliest="16:00",
latest="21:25"
]
Type rangeEvent : set#event [
earliest="16:00",
latest="21:25"
]
Type rangeEvent : civilDawn#start [
earliest="06:05",
latest="08:00"
]
Type rangeEvent : civilDawn#event [
earliest="06:05",
latest="08:00"
]
Type rangeEvent : civilDusk#start [
earliest="16:30",
latest="22:00"
]
Type rangeEvent : civilDusk#event [
earliest="16:30",
latest="22:00"
]
Type rangeEvent : nauticDusk#start [
earliest="22:11",
latest="23:45"
]
Type rangeEvent : nauticDusk#event [
earliest="22:11",
latest="23:45"
]
}
If you are still on 2.0 release you need to upgrade. There was indeed a proven work Astro in the 2.0 release but it was corrected in 2.1 or 2.2, I don’t remember which. So in answer to your question 1, the solution is likely to upgrade.
To use the sunset time as a trigger you will have to set a timer based on the sunset time.
@vzorglub , I can not imagine that it is an SD card problem because I have problems with the Astro-Binding only. @rlkoshak , unfortunately I forgot to mention that I always install the last stable version. I am currently at 2.2.0-1.
The idea with the timer is a mediocre workaround I hope I understand you correct: Starting a rule at 16 o’clock (cron), which then calculates the remaining time until sunset and generates a timer from it? Is not there a better solution?
Personally I use paperui to define my Astro things, but are you sure your channels are defined correctly? According to the docs only the #event channels should be of type rangeEvent, the #start and #end should be Type start and Type end respectively.
@vzorglub: I have ordered a new SD card. I will give it a try
@pacive: I had probably seen it wrong. I have now adjusted my configuration as follows:
astro:sun:myhome [ geolocation="xxxxxxxxxxxxxxxxxxxxxx", interval=240 ] {
Channels:
Type rangeEvent : set#event [
earliest="16:00",
latest="21:25"
]
Type rangeEvent : civilDawn#event [
earliest="06:05",
latest="08:00"
]
Type rangeEvent : civilDusk#event [
earliest="16:30",
latest="22:00"
]
Type rangeEvent : nauticDusk#event [
earliest="22:11",
latest="23:45"
]
}
If I understand those settings correctly, the entire event is delayed or preferred. So the start trigger should still come now at the delayed/preferred time? Currently the sunset is within the time range anyway but in mid-summer it should be preferred and should be delayed in winter (during the “short days”).
@vzorglub: Do you know if I can simply copy the SD card with Win32 Disk Imager or do I need to reinstall and use openhab backup? The second solution would be a lot more effort, because I have also made additional configurations outside of openhab on the linux. Of course, I have not documented these…
You need to do a clean install. Because copying the SD card will also copy the errors!
Clean install linux/raspian…
Clean install openhab
Copy your files from your conf folder in the new install one by one.
The openhab back up may also back up errors (not sure but it just may)
Good luck
Anyway, it’s always good to have a fully functioning back up just in case
Use the Channel event trigger. That is why they exist, to address the need to create timers and other things like this.
Those are your only two options.
There have been no reports of Astro failing to trigger since before the 2.2 release so I think perhaps a mistake in the Thing definition might be the right idea.
The SD card idea could also be a cause but I agree, you need to start fresh because just copying the whole SD card will copy the corruption.
This was a kwown problem of astro binding and is solved with OH2.2.
The reason is, that the astro reschedule sometimes is related to the old day. As I know the developer ships the daily recalc to 1 min after midnight instead of midnight.
As you can see in my first post I am using the event trigger in my rule. The additional configuration for “Type start : set#start” (earliest and latest) is additional to “Type rangeEvent : set#event”. I am using the Type start to have the official (correct astro) time and the adapted (within the timerange) displayed in a sitemap:
DateTime Sonnenunter "Sun set [%1$tH:%1$tM]" (myAstro) { channel="astro:sun:home:set#start" }
DateTime Sonnenunter_rule "Sun set in Rule [%1$tH:%1$tM]" (myAstro) { channel="astro:sun:myhome:set#start" }
Anyway, I will try now first to use the corrected things configuration (Type rangeEvent vs start). If that is not a solution I will try the news SD-card.
I will report my improvements!
Another idea.
Just in case (for some reason) that you don’t have the latest astro binding, you could replace your existing jar with the latest on github…
Just in case
Another stupid question on the subject: I am using openhabian. To update my system I am using openhabian-config… Can it happen that this change was not added? My console shows me openhab 2.2 but can i verify the new setting somewhere?
I hope I understand you correct: Starting a rule at 16 o’clock (cron), which then calculates the remaining time until sunset and generates a timer from it? Is not there a better solution?
