Just checking with the dscAlarm community to see if anyone has migrated their setup from OH2 to OH3? I attempted to migrate early in January and ran into errors getting the binding to start (OH3 dscAlarm binding error). It seemed a little chaotic at the time and I switched back over to 2.5.11.
I’m ready to try this again and thought I’d start by checking in with the dscAlarm binding users for tips and status?
Thanks!
Yes, I upgraded a few weeks ago. I use the Envisalink Ethernet bridge to interface to my DSC control panel. The new OH3 binding connected right away to the bridge and quickly found the panel, partition and all of the zones. Quite a smooth transition and it is working well now on OH3.
Excellent news, thank you!!
Hi Brian!
I got this working on OH3. I think there is still an underlying issue and I’m wondering if you could check your /var/log/openhab/openhab.log and see if this happened on your last boot:
2021-03-21 01:22:21.776 [WARN ] [ab.core.internal.events.EventHandler] - Creation of event failed, because one of the registered event factories has thrown an exception: Error invoking #valueOf(String) on class 'org.openhab.core.library.types.DateTimeType' with value '2-01-01T00:00:00.000-0700'.
java.lang.IllegalStateException: Error invoking #valueOf(String) on class 'org.openhab.core.library.types.DateTimeType' with value '2-01-01T00:00:00.000-0700'.
at org.openhab.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:188) ~[bundleFile:?]
at org.openhab.core.items.events.ItemEventFactory.parseType(ItemEventFactory.java:156) ~[bundleFile:?]
at org.openhab.core.items.events.ItemEventFactory.getState(ItemEventFactory.java:134) ~[bundleFile:?]
at org.openhab.core.items.events.ItemEventFactory.createStateEvent(ItemEventFactory.java:114) ~[bundleFile:?]
at org.openhab.core.items.events.ItemEventFactory.createEventByType(ItemEventFactory.java:78) ~[bundleFile:?]
at org.openhab.core.events.AbstractEventFactory.createEvent(AbstractEventFactory.java:53) ~[bundleFile:?]
at org.openhab.core.internal.events.EventHandler.createEvent(EventHandler.java:131) [bundleFile:?]
at org.openhab.core.internal.events.EventHandler.handleEvent(EventHandler.java:106) [bundleFile:?]
at org.openhab.core.internal.events.EventHandler.handleEvent(EventHandler.java:84) [bundleFile:?]
at org.openhab.core.internal.events.ThreadedEventHandler.lambda$0(ThreadedEventHandler.java:67) [bundleFile:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:179) ~[bundleFile:?]
... 10 more
Caused by: java.lang.IllegalArgumentException: 2-01-01T00:00:00.000-0700 is not in a valid format.
at org.openhab.core.library.types.DateTimeType.<init>(DateTimeType.java:112) ~[bundleFile:?]
at org.openhab.core.library.types.DateTimeType.valueOf(DateTimeType.java:123) ~[bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:179) ~[bundleFile:?]
... 10 more
Caused by: java.time.format.DateTimeParseException: Text '2-01-01T00T00:00:00:00:00.000-0700' could not be parsed at index 0
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2046) ~[?:?]
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1948) ~[?:?]
at java.time.LocalDateTime.parse(LocalDateTime.java:492) ~[?:?]
at org.openhab.core.library.types.DateTimeType.parse(DateTimeType.java:232) ~[bundleFile:?]
at org.openhab.core.library.types.DateTimeType.<init>(DateTimeType.java:106) ~[bundleFile:?]
at org.openhab.core.library.types.DateTimeType.valueOf(DateTimeType.java:123) ~[bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:179) ~[bundleFile:?]
... 10 more
2021-03-21 01:22:21.893 [INFO ] [script.panel trouble message message] - value=PANEL_TROUBLE_MESSAGE (Type=StringItem, State=, Label=Panel trouble message, Category=shield, Groups=[DSCAlarmPanel])
2021-03-21 01:22:21.894 [INFO ] [el.script.system panel error message] - value=PANEL_SYSTEM_ERROR (Type=StringItem, State=, Label=Panel System Error:, Category=shield, Groups=[DSCAlarmPanel])
It looks like this is being caused when the binding tries to initialize using the time value 2-01-01T00:00:00.000-0700. I’m not sure who maintains the binding, but just removing the string would cause it to use the default and initialize with ‘now’.
Gary
Gary,
I got this working on OH3. I think there is still an underlying issue and I’m wondering if you could check your /var/log/openhab/openhab.log and see if this happened on your last boot:
I checked my openhab.log file. Nothing like what you have logged. Not sure why you are having a datetime issue. I have never used datetime variables with the DSC binding.
As per our last conversation, my DSC alarm system is working very well with OH3.
I generally get an error on boot-up from the DSC bridge as follows…
[ERROR] [al.handler.DSCAlarmBaseBridgeHandler] - Not Connected to the DSC Alarm!
…but I also received this same error with OH 2.5.x. I always thought the system was being intitalized too early in the boot-up routine because the bridge does come on line.
Sorry I couldn’t be more help.