Hi,
Pretty new to WebThings but have many years of Home Automation having suffered through decades of X10 fun. I have a WebThings gateway setup on a Raspberry Pi with an Aerotec V5 Z-Wave adapter connected to a test bed with two basic on/off switches. I have gotten them connected in things and they work properly. I added the DateTime add-on and added it to things as well. Setup the time zone and lat/long for my location. Now I am trying a basic rule, at sunset turn on the two switches. Rule parses properly, but come sunset, nothing happens.
Go into the DateTime in things, everything looks right except “Next event” shows a few hundred minutes from now, if sunrise and sunset are events, should they now show properly? Today sunset was 7:39 PM at my lat/long and no event happened. Am I missing something?
Any help would be appreciated, hopefully it is a Homer DOH moment I am missing.
I run the same configuration and don’t have any issues except I run WT using a docker container. You may want to log into your PI and check if the OS has it’s timezone set correctly.
When I inspected the logfile for SUNRISE calculation I noticed it uses UTC as the date in the log file. It must use UTC internally and adjust based on provisioned TZ…
2022-04-14 06:14:08.508 INFO : date-time-adapter: date_device.py:201 INFO now:2022-04-14 06:14:08.505315-05:00 > next:2022-04-14 06:14:07.096896-05:00
2022-04-14 06:14:08.518 INFO : date-time-adapter: date_device.py:205 INFO New event sunrise
2022-04-14 06:14:08.522 INFO : zwave-adapter: setProperty property: on for: zwave-d79b7f78-2-Level valueId: 2-38-1-0 value: zw: 99 (100.0%)
2022-04-14 06:14:08.525 INFO : date-time-adapter: util.py:129 INFO CALC_SUNRISE tdy.utc: 2022/4/14 11:14:09 sunrise: 2022/4/15 11:12:32 sunrise_local: 2022-04-15 06:12:32.007083-05:00
2022-04-14 06:14:08.529 INFO : zwave-adapter: setProperty property: on for: zwave-d79b7f78-3-Level valueId: 3-38-1-0 value: zw: 99 (100.0%)
2022-04-14 06:14:08.532 INFO : zwave-adapter: setProperty property: on for: zwave-d79b7f78-9-Level valueId: 9-38-1-0 value: zw: 99 (100.0%)
2022-04-14 06:15:08.737 INFO : date-time-adapter: util.py:129 INFO CALC_SUNRISE tdy.utc: 2022/4/14 11:15:09 sunrise: 2022/4/15 11:12:32 sunrise_local: 2022-04-15 06:12:32.007083-05:00
It is very weird. I have the PI as well as the DateTime add on configured for Americas/New_York. The PI GUI shows the correct time/date.
The DateTime add-on ended up saying Sunset was 9:35 AM today
The DateTie add-on had Sunrise was 20:21 yesterday.
Neither is close to reality.
The PI is set to Americas/New_York, sunset should be 7:42 PM EDT, which is 11:42 PM UTC and yet the DateTime add in is doing an event at 9:42 AM.
So I have two sets of rules:
1A - turn on lights at sunset
1B - turn off lights at 11 PM
2A - turn on lights at 5 AM
2B - turn off lights at sunrise
1A is going off at 9:xx am 14 hours after it should happen.
1B is going off at correct time
2A is going off at correct time
2B is going off at 8:XX PM also 14 hours after it should
No idea why the sunrise/sunset are so far out of wack
I wonder why 1 set of rules work as expected and others don’t… It seems that DateTime calculations may not be the issue because some events work ok. It’s calculations must be correct. If you inspect today’s logfile you should be able to find where DateTime re-calculates Sunrise. It uses this common time to fire all linked timers. It should be similar to the screenshot I posted earlier.
Assuming Sunrise/Sunset and the UTC offset is correctly identified I would then create a new test rule to see if it fires at the calculated time. If it does, then I’d delete one of your faulty rules & re-create it so it fires on only 1 device.
I know I had to debug a rule that triggered multiple devices one time for some forgotton reason… Think I asked here if devices were triggered in parallel or serially and what happened if 1 device hung (which I think was my issue at the time). Probably does not apply to this issue though…
I have not been able to find that log file that has CALC_SUNRISE log.
Looked in:
/var/log
/home/pi/.webthings/log
Did a few:
grep -iR sunrise *
No sign of it 
Where is yours located?
You can view it using the GUI: Settings -> Developer -> Internal Logs
You may also want to review the DateTime addon “config” settings to verify that it’s provisioned to display at least INFO messages, which should be the default value (I think).
It was set to warning, changed it to info, we’ll see what it says next time it recalculates and I’ll update here.
Very weird - it is calculating them wrong:
2022-04-18 14:09:06.916 INFO : Unloading DateTimeAdapter
2022-04-18 14:09:14.202 INFO : Loading add-on: date-time-adapter
2022-04-18 14:09:15.555 INFO : date-time-adapter: date_adapter.py:37 INFO Log level 30
2022-04-18 14:09:16.024 INFO : date-time-adapter: util.py:129 INFO CALC_SUNRISE tdy.utc: 2022/4/18 18:09:16 sunrise: 2022/4/19 00:14:25 sunrise_local: 2022-04-18 20:14:25.188959-04:00
2022-04-18 14:09:16.026 INFO : date-time-adapter: util.py:153 INFO CALC_SUNSET today.utc: 2022/4/18 18:09:16 sunset: 2022/4/19 13:39:06 sunset_local: 2022-04-19 09:39:05.602880-04:00
2022-04-18 14:09:16.028 INFO : date-time-adapter: util.py:27 INFO DTS lat: 39.78 lng: 75.69
2022-04-18 14:09:16.030 INFO : date-time-adapter: util.py:129 INFO CALC_SUNRISE tdy.utc: 2022/4/18 18:09:16 sunrise: 2022/4/19 00:14:25 sunrise_local: 2022-04-18 20:14:25.188959-04:00
2022-04-18 14:09:16.038 INFO : date-time-adapter: util.py:153 INFO CALC_SUNSET today.utc: 2022/4/18 18:09:16 sunset: 2022/4/19 13:39:06 sunset_local: 2022-04-19 09:39:05.602880-04:00
2022-04-18 14:09:16.040 INFO : date-time-adapter: date_device.py:96 INFO sunset: 2022-04-19 09:39:05.602880-04:00 sunrise: 2022-04-18 20:14:25.188959-04:00
2022-04-18 14:09:16.042 INFO : date-time-adapter: date_device.py:37 INFO DateTimeDevice started
Is there some update I need to do to get accurate sunrise/sunset information for my Lat/Long? It just seems completely backwards like a table of values is corrupted. Tried changing timezone to America/Montreal - moved the lat/long a little - still not anywhere close to reality.
On my system, I’ve provisioned: America/Chicago, and also the LAT AND LONG vaules too. Noticed in your INFO output that you may have a POSITIVE value specified for LONG rather than a NEGATIVE VALUE… Here is my setting for Chicago.
Nice catch! I am not a lat/long person, so it is a bit confusing below is what I looked up:
Hockessin, DE
Hockessin is a Populated Place in New Castle County , Delaware . It has an elevation of 78 meters , or 256 feet .
Degrees Minutes Seconds:
Latitude: 39-47’15’’ N
Longitude: 075-41’48’’ W
Decimal Degrees:
Latitude: 39.7876112
Longitude: -75.6966001
One is positive, one it negative, I changed long to negative and it looks much better now:
2022-04-19 09:16:47.100 INFO : date-time-adapter: util.py:27 INFO DTS lat: 39.47 lng: -75.41
2022-04-19 09:16:47.104 INFO : date-time-adapter: util.py:129 INFO CALC_SUNRISE tdy.utc: 2022/4/19 13:16:47 sunrise: 2022/4/20 10:17:15 sunrise_local: 2022-04-20 06:17:14.564786-04:00
2022-04-19 09:16:47.111 INFO : date-time-adapter: util.py:153 INFO CALC_SUNSET today.utc: 2022/4/19 13:16:47 sunset: 2022/4/19 23:43:28 sunset_local: 2022-04-19 19:43:27.891280-04:00
2022-04-19 09:16:47.116 INFO : date-time-adapter: date_device.py:96 INFO sunset: 2022-04-19 19:43:27.891280-04:00 sunrise: 2022-04-20 06:17:14.564786-04:00
2022-04-19 09:16:47.119 INFO : date-time-adapter: date_device.py:37 INFO DateTimeDevice started