Thanks for the info! 
This is a setup that I’ve not tested, the new design assumes you have an alarm.
I need to look into this and it will be hard for me to test since I only have one SmartLock and also an alarm.
Is it possible that you can test new jar-builds for me?
I will look into this use-case during the week-end.
BR,
/Janne
I can be a guinea pig no worries.
Robin
I cannot reproduce the problem in my IDE 
, I’ve used the JSON posted above with 2 SmartLocks and no alarm and simulated your environment.
I’ve sent you a PM asking for JSONs for the following queries:
https://mypages.verisure.com/overview/climatedevice
https://mypages.verisure.com/settings/smartplug
https://mypages.verisure.com/settings/doorwindow
https://mypages.verisure.com/overview/doorlock/2AQSxxxx use your real ID)
https://mypages.verisure.com/overview/doorlock/2AXDxxxx (use your real ID)
https://mypages.verisure.com/overview/usertrackingcontacts
https://mypages.verisure.com/overview/ethernetstatus
BR,
/Janne
Hi, regarding the refresh/polling of 10 minutes. I took a very quick look at the decompiled Android app, and it is certainly using Google Cloud Messaging (retired and being replaced by Firebase Cloud Messaging this spring). Have you tried to write a small client registering at GCM for push messages?
Regards, Arne
Have you tried to write a small client registering at GCM for push messages?
No, I have not tested that.
There is a decompiled API for Apps that the binding in the future probably should use. If we should make an attempt to get the binding official in OH2.5, I think we will stick with the current implementation.
Using 10 minutes refresh time seems to be acceptable.
I have a fix for @RobinS configuration that works acceptable, code is pushed and I’ve created a new jar-file for test, and updated the link in my original post.
BR,
/Janne
Big thanks for updating and getting the binding up an running again.
I installed 2.5.0.201903031210 on my testsystem and it seems to work alright. After installing in my production system (2.5.0.M1) initially it looked like working but now all readings are null and my smartlocks does not respond to commands.
I should also note that i only have the bridge statement in my things file and explicit define my items in an item file.
Debug logs looks like the actual get correct readings, but the state of the items does not reflect that.
/t
Thank you for testing the binding!
I’m in a process of trying to get this binding official so I’ve done some changes to the logic and modelling after a couple of code reviews.
However, if the previous jar-file worked in one installation but not in another, that seems strange.
Do you run 2.5.0.M1 in both installations? I’m still running on 2.4.0 in my production, I will probably upgrade to a 2.5.0 milestone build soon.
I’ve updated my post above with a new jar-file and an updated README, it you got the time it would be interesting for me to get your test results from the new published jar-file.
The biggest change is that each Thing now has a mandatory property called deviceId. If you’re using autodiscovery the deviceId will be automatically set to the corresponding Verisure Id for that particular device (besides for alarm, broadband connection and user presence that lacks a Verisure Id).
Since you are configuring things in a .things file, you must adapt to this change.
The README file is updated to reflect the change.
BR,
/Janne
Jan,
It looks like the same behaviour to mee.
I really don’t understand your comment regarding deviceId. I configure my stuff in an items file, not .things.
I get debug responses like these:
2019-03-13 14:59:27.328 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP GET: https://mypages.verisure.com/overview/doorlock/2AXABCDE
2019-03-13 14:59:27.378 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (200) Body:
2019-03-13 14:59:27.382 [DEBUG] [ng.verisure.internal.VerisureSession] - REST Response (null)
The items i describe in my items file looks like this:
Switch LF_VS_BoilerRoom_DoorLock_Set “Pannrum dörrlås” { channel=“verisure:smartLock:1:2AXA_BCDE:setSmartLockStatus” }
as the things I see in the inbox after autodiscovery has the underscore in its name.
Is that a problem?
/t
I really don’t understand your comment regarding deviceId. I configure my stuff in an items file, not .things.
NP, in OpenHAB 2.x you have a choice to either configure Verisure Bridge/Things via PaperUI as you have done and then use autodiscovery to detect your Verisure devices, or you can configure Bridge/Things manually in a .things file.
If you use autodiscovery as you have done, deviceId is set automatically so you do not need to bother about it. DeviceId is the same as Verisure Id for most things, except for alarm, user presence and broadband connection.
The items i describe in my items file looks like this:
Switch LF_VS_BoilerRoom_DoorLock_Set “Pannrum dörrlås” { channel=“verisure:smartLock:1:2AXA_BCDE:setSmartLockStatus” }
as the things I see in the inbox after autodiscovery has the underscore in its name.
Is that a problem?
No, it is not a problem. For some reason the Verisure DeviceId for SmartLock does not contain a space in the API, the binding currently adds a “_” between the group of 4 characters so that all DeviceIds looks the same.
Have you configured pin when you configured the Verisure Bridge in PaperUI?
I think I need more Debug info to know what goes wrong, I’ll send a private message to you so that we don’t expose your DeviceIds in public.
The root-cause to the problem mention in previous post was that the Verisure user used when configuring the Bridge did not have sysadmin rights.
I’ve now updated the binding to support users not being sysadmins, however you will then loose some SmartLock functionality but you will be able to lock/unlock the door.
Jan,
It works great with lower privileges, thanks!
What kind of functionality would be missing not using admin rights?
/t
It works great with lower privileges, thanks!
Gr8 to hear, thanks for testing! 
What kind of functionality would be missing not using admin rights?
From the updated README:
Using an older version of the binding on OH2.4 a while back and PaperUI I had a working configuration.
I recently installed a fresh 2.5.0.M1 system and now with the latest binding from this post, I am unable to get the bridge to initialize using .things and .items files. There must be something wrong with my configuration files. The log shows:
[.ItemChannelLinkAddedEvent] - Link 'VS_AlarmStatus-verisure:alarm:myverisure:alarm_1:alarmStatus' has been added.
[.ItemChannelLinkAddedEvent] - Link 'VS_AlarmTime-verisure:alarm:myverisure:alarm_1:timestamp' has been added.
[hingStatusInfoChangedEvent] - 'verisure:bridge:myverisure' changed from UNINITIALIZED to INITIALIZING
[hingStatusInfoChangedEvent] - 'verisure:alarm:myverisure:alarm_1' changed from UNINITIALIZED to UNINITIALIZED (BRIDGE_UNINITIALIZED)
[hingStatusInfoChangedEvent] - 'verisure:bridge:myverisure' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR)
[hingStatusInfoChangedEvent] - 'verisure:alarm:myverisure:alarm_1' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
[hingStatusInfoChangedEvent] - 'verisure:alarm:myverisure:alarm_1' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE)
The thing definition is:
Bridge verisure:bridge:myverisure "VeriSure Bridge" [username=<redacted>, password=<redacted>, refresh="600", pin=<redacted>, numberOfInstallations="1"]
{
Thing alarm alarm_1 "Verisure Alarm" [ deviceId="alarm_1" ]
}
And a few items:
String VS_AlarmStatus "Alarm Status" {channel="verisure:alarm:myverisure:alarm_1:alarmStatus"}
String VS_AlarmTime "Alarm Update" {channel="verisure:alarm:myverisure:alarm_1:lastUpdate"}
I double-checked the login credentials (copied them from the .things file into a new incognito browser session to login to mypages.verisure.com).
What am I missing?
UPDATE: I noticed two things so far:
en_GB as locale. Not sure yet if it matters…[DEBUG] [ng.verisure.internal.VerisureSession] - Login URL: https://mypages.verisure.com/j_spring_security_check?locale=en_GB
UPDATE 2: I can confirm that the special characters - as expected - in the password cause issues with the URL. After changing it to something without those characters, the login succeeds!
@jannegpriv Would it be possible for you to implement encoding of these characters (like described on Wikipedia)?
UPDATE 3: By putting the encoded characters in the bridge definition, the login succeeds (e.g. use %21 instead of ! in the password text). Now I get the alarm status again.
Hi!
Thanks for testing the binding and a nice finding with special characters in the password.
I’ll try to fix that ASAP!
@jannegpriv: One more question, if I may. From the README I concluded that motion sensors are not yet supported in the binding. Correct?
FYI, I have two types of motion sensors (so called Photo Sensors and simple Motion Sensors):
I have the same photo sensor as you do, however I’ve never been able to receive any motion detection status from it. The binding uses the same API as the webpage, is it possible to get information from the motion sensors on the webpage?
Will have a look tomorrow.
Thanks! I can conform that proper URL encoding is happening now. 
