I just recently upgraded to OH 3.3.0.M2 and as the topic states, I do not see a system_date channel on my controller thing. I was on 3.1 and believe it was there (as sysdate) but I am not able to find it under 3.3.0.M2.
I actually own a Lumina Controller, but so far that hasnt been a problem with the binding. Everything else seems like it still works.
Any help would be appreciated.
The screenshot is of my controller thing channels:
@ndye correct me if I’m wrong, but I believe this was fixed post M2 release and should be fixed in the latest snap shot.
Because the channel was changed users will have to delete their omnipro bridge thing and re-add it. It should automatically pick up all of your things linked to the bridge after re-adding it so nothing should be lost.
Thank you @ndye. Deleting and re-adding the thing got me the correct channel. However, when I set the time in a DSL rule, the Lumina sunrise and sunset values update to PST times vs DST times. The actual time is correct, but its like the DST flag on the set controller time screen from PC Access isnt set.
I re-installed the 3.2.0 version of the binding and verified it happens there as well. My initial upgrade was because I noticed my PC Access programs that relied on DARK or Sunset rules were happening an hour early. I upgraded to 3.3.0.M2 thinking it would be fixed, but it still happens.
The command I use to set time is exactly what is listed in the binding:
LuminaTime.sendCommand( new DateTimeType() )
Here is a screenshot of PC Access before I trigger the sendCommand - Notice Sunrise and Sunset are 6:56AM and 6:56PM
Here is a screenshot of PC Access after I trigger the SendCommand – Sunrise and Sunset go back to 5:56AM and 5:56PM while the time is correct.
The way I fix it, is by toggling the controller time with the DST flag
I hope this makes sense.
Any help is greatly appreciated.
Jerry
I suspect that the system that run openHAB is not updating its timezones correctly as for me it does not display that issue.
I checked that. This looks right
openhabian@openhabian3pi:/srv/openhab-addons $ timedatectl
Local time: Thu 2022-03-17 13:22:21 PDT
Universal time: Thu 2022-03-17 20:22:21 UTC
RTC time: n/a
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
openhabian@openhabian3pi:/srv/openhab-addons $My PC Access is running on a Windows machine where it uses UTC-8 Pacific Time for its clock with a toggle to adjust for DST. On my raspberry pi where OH is running, the TZ is set America/Los_Angeles which is currently set to UTC-7 until 3/27 when the UK enters DST. After 3/27 it should go back to UTC-8 and I am assuming all will be fine. But its really driving me nuts why the system isnt accounting for the 2 week period where we have switched over to DST but the UK hasn’t.
Thanks for your help, I get this isn’t a binding issue and if I figure this out, I’ll post a solution. Otherwise, I’ll just wait 2 weeks for it to straighten itself out.
I wonder if maybe it is an PC Access / Lumina issue not accounting for the fact that the UK daylight savings is different from US
It works properly from PCAccess on my Win10 machine but not from OH on raspberry pi.
Is there some optional flag in the API that may need to be set when DST is active?
@ndye I found this on the omnilink protocol for setting the time
SET TIME COMMAND
This message is used to set the time, date, and daylight savings time flag in an HAI controller.
Start character 0x21
Message length 0x08
Message type 0x13
Data 1 year (0-99)
Data 2 month (1-12)
Data 3 day (1-31)
Data 4 day of week (1-7)
Data 5 hour (0-23)
Data 6 minute (0-59)
Data 7 daylight savings time flag (0-1)
CRC 1 varies
CRC 2 varies
Expected reply ACKNOWLEDGE
I also see that you are using a bool inDaylightSavings below in “Data 7”
case CHANNEL_SYSTEM_DATE:
if (command instanceof DateTimeType) {
ZonedDateTime zdt = ((DateTimeType) command).getZonedDateTime();
boolean inDaylightSavings = zdt.getZone().getRules().isDaylightSavings(zdt.toInstant());
try {
getOmniConnection().setTimeCommand(zdt.getYear() - 2000, zdt.getMonthValue(),
zdt.getDayOfMonth(), zdt.getDayOfWeek().getValue(), zdt.getHour(), zdt.getMinute(),
inDaylightSavings);
} catch (IOException | OmniNotConnectedException | OmniInvalidResponseException
| OmniUnknownMessageTypeException e) {
logger.debug("Could not send Set Time command to OmniLink Controller: {}", e.getMessage());
}
} else {
logger.debug("Invalid command: {}, must be DateTimeType", command);
}
break;
I need to see if I can build this binding so that I can debug it. It seems like the bool should be TRUE right now, but I’d like to verify that is what is being passed to the Lumina.
Thanks,
Jerry
@ndye I found the issue but I’m not sure on how to fix this. Here is what is happening:
The value for inDaylightSavings is returning false because the value of command is
2022-03-25T14:41:49.061745-0700 instead of
2022-03-25T14:41:49.083824-07:00[America/Los_Angeles]
The getZone method returns -0700 vs America/Los_Angeles and there are no Rules setup for -0700.
When I replaced the input with .now() method in the code, the value for inDaylightSavings returned true.
It seems like the right solve is for the OH Rules to format the date properly when I call the following function LuminaTime.sendCommand( new DateTimeType( now ) ) but that doesnt seem to be happening.
Any thoughts on your part would be appreciated. All this ZoneDateTime stuff is really not that easy to understand. Temporarily, I can add the TimeZone to the string in command before casting it to a ZonedDateTime in the code, but that seems wrong.
Here is my fix:
replace this line:
boolean inDaylightSavings = zdt.getZone().getRules().isDaylightSavings(zdt.toInstant());
with this line
boolean inDaylightSavings = ZoneId.systemDefault().getRules().isDaylightSavings(zdt.toInstant());
Instead of using the ZoneId from the value passed into the method, I use the ZoneId of the system to determine if DST is active. This change seems to fix my issue.
If I can figure out how to do a PR I will submit this change.
Thanks,
Jerry
Hmm. this is very interesting because my system updated for daylight savings perfectly. I use a JavaScript rule through the openHAB Main UI. I wonder if you tried to use the JS rule if it would work and it is just an issue with the old rules that is causing the discrepancy. Here is the JS rule that I use:
events.sendCommand('OmniLinkController_DateTime', new DateTimeType())
I don’t completely like the fix proposed above because it circumvents the input from the user and if they try to add a custom date/time (i.e. not the same as their system) it may not always match. I realize that this is a very unlikely circumstance, however I always like my code to work in as many situations as possible.
I am getting the same results with JavaScript. Can you tell me what version of Java you are running? I am on the following version:
openhabian@openhabian3pi:~ $ java -version
openjdk version "11.0.13" 2021-10-19 LTS
OpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)
OpenJDK Client VM Zulu11.52+13-CA (build 11.0.13+8-LTS, mixed mode)
Also, are you in Arizona or Hawaii by any chance?
What is the serialized value of DateTimeType()?
I get the ISO8601 format of 2022-03-27T13:03:35.556-0700
Finally, what happens when you run this?
import java.util.*;
import java.time.ZonedDateTime;
import java.time.ZoneId;
import java.time.Instant;
public class ZonedDateTimeDemo {
public static void main(String[] args) {
// String tz = "America/Los_Angeles";
String tz = "-0700";
boolean inDaylightSavings = ZoneId.of(tz).getRules().isDaylightSavings(Instant.now());
System.out.println("inDaylightSavings for tz " + tz + " = " + inDaylightSavings);
}
}
BTW, the fix doesn’t exactly circumvent the input from the user. It still uses the date and time portion of the input. It just uses the system time zone at the user input date & time to determine if DST is active at that instant. But I get what you’re saying. It seems like TZ id should be an explicit input into the method, but its not at the moment. And DST in not deterministic based on TZ offset alone. You need locale to make it deterministic.
At the moment, I’m just trying to understand why you have a working system and I don’t. In my mind, unless you live in Arizona or Hawaii your system should not work either.
Thanks for your help,
Jerry
Alright, one annoying debugging effort later, I have come up with a more clever solution. I’ve submitted a PR for it, you can track its progress here.
I forgot that I recently switched from using the OmniPro’s sunset calculation to the Astro binding and that was why I kept seeing the correct results as my Daylight Savings just so happened to already be turned on.
Once my patch is merged you will just need to provide a input to the system_date channel (now a string for stupid reasons) like so:
var ZonedDateTime = Java.type("java.time.ZonedDateTime");
var ZoneId = Java.type("java.time.ZoneId");
var zdt = ZonedDateTime.now(ZoneId.of("America/Denver"));
events.sendCommand('DateTime', new StringType(zdt));
And for reference, if it wasn’t clear I live in Utah or MDT/MST.
Not super user friendly but ok. Thanks for your help. Glad it wasn’t just me that had the issue. I can’t imagine there are many folks left with a HAI controller so thank you for maintaining and keeping this binding alive
Jerry
Not really user friendly, but because DateTimeType does not preserve the location data needed to check if we are in DST it was necessary to bypass it making it more complex.
I maintain this because I had the same issue when I started a few years back. Nobody was and I really liked the functionality that it offered and I still do, so its no problem. Plus, I enjoy it.