Hi, i am running Openhab 2.5.2 and using the astro binding.
A few weeks ago the Wintertime was started and now my rollers are running at the wrong time.
In the paper ui i had set an offset of 60 minutes for the End of Local Sunset but still the roller is going down at the old time, in the Control of Paper UI i see the right time but the roller starts an hour earlier at 16:53
Anybody who had the same problem ?
Could you explain a bit more in detail about your setup ? Is it windows or linux based ?
How does your rule that controls the rollers look like ?
I am using the astro binding to turn on / switch off lights. When the change to wintertime started I hadn’t to change anything to get the lights swtiched on / off the next day as the time of the system was “changed” by the OS itself.
I have a vague recollection that there was a bug in Astro that has been fixed related to this in the roughly 8 months since OH 2.5.2 came out. I’d recommend updating to 2.5.10 and if the problem persists come back with logs. For Astro it’s most helpful to get logs at around midnight where it logs about calculating the timers for the new day (which causes the rule to trigger) and logs around the time that the event actually occurs.
Hi Wolfgang,
I use a Raspberry 3B+ and installed OS Buster on a ssd
On that ssd i installed Openhab2.5.2 and that was running fine.
in the log i see that SunSet end is triggerd en the roller is is closing to 100 %
i use a very simple rule for it and also send a Telegram message about it.
"
2020-11-16 16:53:00.006 [vent.ChannelTriggeredEvent] - astro:sun:local:set#event triggered END
2020-11-16 16:53:00.014 [vent.ChannelTriggeredEvent] - astro:sun:local:civilDusk#event triggered START
==> /var/log/openhab2/openhab.log <==
2020-11-16 16:53:00.025 [INFO ] [.eclipse.smarthome.model.script.info] - Is Keuken Rolluik dicht na Local Sunset END ?
==> /var/log/openhab2/events.log <==
2020-11-16 16:53:00.072 [ome.event.ItemCommandEvent] - Item ‘velux_rollershutter_home_Keuken_position’ received command 100
2020-11-16 16:53:00.075 [nt.ItemStatePredictedEvent] - velux_rollershutter_home_Keuken_position predicted to become 100
Rule “Astro trigger Down rule”
when
Channel ‘astro:sun:local:set#event’ triggered END
then
sendCommand(velux_rollershutter_home_Keuken_position, 100)
logInfo("info","Is Keuken Rolluik dicht na Local Sunset END ? ")
telegramAction.sendTelegram("Sunset END, Rolluik keuken gaat sluiten")
end
But i have also seen the reaction of Ricoshak and found some posts on the Community about it, so maybe i will first going to upgrade to 2.5.10 and see how that is running.
I found some posts about it and will try to upgrade to 2.5.10 and see if it solve this, thanks.
Hi, i have upgraded to 2.5.10 but without any changes.
The logs around midnight shows the following
2020-11-18 00:00:30.900 [vent.ItemStateChangedEvent] - astro_sun_local_set_start changed from 2020-11-17T16:48:00.000+0100 to 2020-11-18T16:47:00.000+0100
2020-11-18 00:00:30.915 [vent.ItemStateChangedEvent] - astro_sun_local_set_end changed from 2020-11-17T18:02:00.000+0100 to 2020-11-18T18:01:00.000+0100
2020-11-18 00:00:30.931 [vent.ItemStateChangedEvent] - astro_sun_local_noon_start changed from 2020-11-17T12:30:00.000+0100 to 2020-11-18T12:30:00.000+0100
2020-11-18 00:00:30.935 [vent.ItemStateChangedEvent] - astro_sun_local_noon_end changed from 2020-11-17T12:31:00.000+0100 to 2020-11-18T12:31:00.000+0100
2020-11-18 00:00:30.939 [vent.ChannelTriggeredEvent] - astro:sun:local:morningNight#event triggered START
2020-11-18 00:00:30.943 [vent.ItemStateChangedEvent] - astro_sun_local_astroDusk_start changed from 2020-11-17T18:11:00.000+0100 to 2020-11-18T18:10:00.000+0100
2020-11-18 00:00:30.947 [vent.ItemStateChangedEvent] - astro_sun_local_astroDusk_end changed from 2020-11-17T18:50:00.000+0100 to 2020-11-18T18:49:00.000+0100
But astro:sun:local:set::end is triggered 1 hour to early
Here the log around 17:00 hours
2020-11-18 16:51:00.003 [vent.ChannelTriggeredEvent] - astro:sun:local:set#event triggered END
2020-11-18 16:51:00.011 [vent.ChannelTriggeredEvent] - astro:sun:local:civilDusk#event triggered START
2020-11-18 16:51:00.023 [ome.event.ItemCommandEvent] - Item ‘velux_rollershutter_1d4a1268_Keuken_position’ received command 100
==> /var/log/openhab2/openhab.log <==
2020-11-18 16:51:00.025 [INFO ] [.eclipse.smarthome.model.script.info] - Is Keuken Rolluik dicht na Local Sunset END ?
==> /var/log/openhab2/events.log <==
2020-11-18 16:51:00.061 [nt.ItemStatePredictedEvent] - velux_rollershutter_1d4a1268_Keuken_position predicted to become 100
2020-11-18 16:51:00.095 [vent.ItemStateChangedEvent] - velux_rollershutter_1d4a1268_Keuken_position changed from 0 to 100
Which Channel did you ally the offset to? You need to apply it to the event Channel.
I did it on the channel of astro:sun:local:set:end
What is the event channel ?
Do you have a example for me ?
You need to do it on the Range Event Channel to trigger your rule
I am sorry but it cant put in a time in the range event at earliest or latest, when i put a time at earliest say 18:00 and 18:30 at latest i get warnings in the log like below
2020-11-19 15:43:42.882 [WARN ] [ng.astro.internal.util.DateTimeUtils] - Can not parse astro channel configuration '1970-01-01T17:30:00.000Z' to hour and minutes, use pattern hh:mm, ignoring!
2020-11-19 15:43:42.887 [WARN ] [ng.astro.internal.util.DateTimeUtils] - Can not parse astro channel configuration '1970-01-01T17:30:00.000Z' to hour and minutes, use pattern hh:mm, ignoring!
It is referring to the first of januari in the year 1970 ???
But i dont know why, from where is this coming ?
Btw, i am doing this in paper ui, i am not using text files.
It kind of looks like there might be a bug in PaperUI for setting the offset in this case. I’m not sure whether or how easily it would be fixed given that all development has moved to OH 3 now. I can confirm that it works in OH 3 and MainUI.
The 1970 is coming from the fact that a date is not being defined. A DateTime represents an instant in time. Almost all computers use something called epoch to represent time. Epoch is just a big number that is counting the number of milliseconds that have passed since 1970-01-01T00:00:00 (midnight on new years 1970 GMT). Since you only defined an hour and minute, which is all you should define, it defaulted the date time parts to 0.
The problem appears that it’s converting your input to a DateTime too soon.
You can file an issue (not sure if it’s a PaperUI or an Astro binding problem) and hope it gets fixed, upgrade to OH 3 where I know it works (which implies it’s actually a PaperUI problem), or stop openHAB, open the JSONDB things file and manually fix the entries to use hh:mm as the times.
Hi Rich,
thanks you for the message and info you gave me.
But is there already a way to upgrade to openhab 3 by uding openhabian-config as far as you know ?
And if not can you tell me the path to the jasondb things file ?
I think that openHABian supports OH 3 now.
/var/lib/openhab2/jsondb
Hi Rich,
i just noticed that now the roller has just being closed as i want with an offset of 60 and without earliest or latest specified.
Again thanks for the help.
@ rlkoshak
Fixing the jsondb things file did do the job. Everything works like a charm.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.