The build system was changed after OH3.0, which version of OH3.x are you running? I’ve tested it on 3.2.0.M2.
Im running 3.0.1, should I update OH to the milestone (3.2.0.M2) and test?
In that case the Versure binding will work, for me 3.2.0.M2 seems stable. 
Updated OH to 3.2.0M2 and now it works
1 Like
Looks like back to “normal” status again.
I’m running openhabian stable which currently is 3.1.0.
Thank you very much
/t
1 Like
I have tested the 2.5.x version, running on Openhab 2.5.9, and it all works as expected.
Thank you very much for the update Janne!
1 Like
I put the 3.2.0…jar on my system. The bridge now connects without any problems and it comes online, which it was not doing before 
I disabled / enabled it a few times to double check it and it worked every time. However, the channels of the Things are not updating (this was also happening before), and I see this list of errors in the log file every time I re-enable the bridge:
2021-09-15 21:18:56.999 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to query for climate status: java.lang.IllegalStateException: Expected BEGIN_ARRAY but was STRING at line 1 column 1 path $
2021-09-15 21:18:57.151 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to query for climate status: java.lang.IllegalStateException: Expected BEGIN_ARRAY but was STRING at line 1 column 1 path $
2021-09-15 21:18:57.298 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to query for climate status: java.lang.IllegalStateException: Expected BEGIN_ARRAY but was STRING at line 1 column 1 path $
2021-09-15 21:18:57.572 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to query for climate status: java.lang.IllegalStateException: Expected BEGIN_ARRAY but was STRING at line 1 column 1 path $
2021-09-15 21:18:57.721 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to query for climate status: java.lang.IllegalStateException: Expected BEGIN_ARRAY but was STRING at line 1 column 1 path $
2021-09-15 21:18:57.788 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API Invalid session cookie
2021-09-15 21:18:57.852 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API Invalid session cookie
2021-09-15 21:18:57.914 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API Invalid session cookie
2021-09-15 21:18:57.979 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API Invalid session cookie
2021-09-15 21:18:58.048 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API Invalid session cookie
2021-09-15 21:18:58.129 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API Invalid session cookie
Actually, at midnight last night the things started regularly updating. Maybe because of previous binding problems I had reached my maximum number of requests for a day. I will check the log file again when I get a chance.
Seems like I was a bit too fast in my “ok”.
Bridge is online and all things associated to it (except eventlog, which is fine if it’s unrelated), however - I noticed that refresh didn’t work. I changed the refresh interval to test and then got the warning below, also notice the Forbidden for eventlog… Any idea what can be the cause of this? I have trace logs if needed.
2021-09-16 13:56:23.454 [DEBUG] [ng.verisure.internal.VerisureSession] - Setting cookie with username openhab@andreasbergkvist.com
2021-09-16 13:56:23.456 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP POST Request HttpRequest[POST /graphql HTTP/1.1]@1550fb7.
2021-09-16 13:56:23.526 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (200)
2021-09-16 13:56:23.528 [TRACE] [ng.verisure.internal.VerisureSession] - Response body: {"errors":[{"message":"Request Failed","locations":[{"line":3,"column":2}],"path":["installation","eventLog"],"data":{"status":403,"logTraceId":"ca832e9d-b405-4a1c-bd8a-592de75bd9a9","errorGroup":"FORBIDDEN","errorCode":"AUT_00055","errorMessage":"User does not have permission to access the requested resource"}}],"data":{"installation":{"eventLog":null,"__typename":"Installation"}}}
2021-09-16 13:56:23.530 [DEBUG] [ng.verisure.internal.VerisureSession] - REST Response (VerisureBaseThingDTO [deviceId=, name=null, location=null, status=null, siteName=null, siteId=0, data=Data [installation=Installation [armState=ArmState [type=null, statusType=null, date=null, name=null, changedVia=null, allowedForFirstLine=false, allowed=false, errorCodes=[], typename=null], broadband=Broadband [testDate=null, isBroadbandConnected=false, typename=null], eventLog=null, climates=[], doorWindows=[], communicationState=[], mice=[], doorlocks=[], smartplugs=[], userTrackings=[], typename=Installation]]])
2021-09-16 13:56:23.533 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.verisure.internal.dto.VerisureBaseThingDTO$Installation.equals(VerisureBaseThingDTO.java:376) ~[?:?]
at org.openhab.binding.verisure.internal.dto.VerisureBaseThingDTO$Data.equals(VerisureBaseThingDTO.java:231) ~[?:?]
at org.openhab.binding.verisure.internal.dto.VerisureBaseThingDTO.equals(VerisureBaseThingDTO.java:150) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.notifyListenersIfChanged(VerisureSession.java:567) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.updateEventLogStatus(VerisureSession.java:942) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.updateStatus(VerisureSession.java:591) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.refresh(VerisureSession.java:127) ~[?:?]
at org.openhab.binding.verisure.internal.handler.VerisureBridgeHandler.refreshAndUpdateStatus(VerisureBridgeHandler.java:183) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
Is the user you are using for the automation an administrator in your system?
No, it is a user with read only permissions. Which has worked well previously.
OK, since I only use an automation user with administrator rights since I want to control my SmartLock I have not seen that fault. What happens is that the binding fails to parse the output from the eventLog since that requires ad admin user, then the NPE will cause the refresh thread to die.
I will try to fix that but then the eventLog information will not be available. What puzzles me is that the fix I have done has not touched that code, but maybe you have added the eventLog thing now?
A w.o. could then be to delete it.
Ah, I see. I only use read only data (like change in alarm state) as input to other events and therefore I’d like to run with a limited user.
As I was on a quite old version of the binding, I had not seen the eventLog thing before. I did add it, but when I saw that it wasn’t functional, I removed it. I guess that the thing is still lingering in the database even though it’s removed in Paper UI.
Thanks, then I have an approach to fix this - making sure that the eventLog thing is properly removed.
As a side note, regarding MFA and a limited user. It is possible to elevate a user to administrator, disable MFA, and then lower the rights to e.g. read only again.
Cheers!
I’ve just checked that and it is possible if you lower the rights being logged in as another admin user. 
Yes, that’s a good clarification of how to do it
@raveyd @AndreasB I’ve now tested with a user that is not an administrator and that it not supported by the current binding implementation since a number of endpoints that the bindings uses are not allowed to query if you are not an administrator.
That in turn leads to that the binding behaves badly and e.g. that the refresh thread is killed.
This might have worked before the latest changes that Verisure has implemented regarding authentication, so that might explain why it worked before.
For the moment I will not spend time on having support for both basic and administrator users and I will update the README that it currently is mandatory to use a user with administrator rights and with MFA deactivated.
Thank you for the update @jannegpriv.
Edit after some more testing:
@jannegpriv, it is actually possible to have a Verisure user with “Restricted” privileges and have a functional binding (caveat, I have not tested with eventLog). So, full administrative rights seems not to be needed for my use case where I only read statuses, but the user level “Minimum” is not sufficient.
If that works for you then it is all good, when I tested I got a lot of 302’s since endpoints were not allowed to be queried, but for the official documents I will still state that you need to use a user with administrator rights. Thanks for testing!
New version for upcoming 3.2.0, code reviewed and with som bug fixes for NPEs:
3.2.0
md5sum org.openhab.binding.verisure-3.2.0-SNAPSHOT.jar
a9e6952abcbf44ede5a0ee56b2d79d6c org.openhab.binding.verisure-3.2.0-SNAPSHOT.jar